A Personal History of Collaboration

You may be thinking, “Who is this guy with the audacity to write about his personal history? I’ve never heard of him.” Why should you, the reader, care?

We bring value to ourselves and others by introspecting about our experiences and mining the nuggets of wisdom they contain. An authentic story tends to resonate a bit more, and you might even remember the nugget it contains down the road.

With that clever rationalization for telling a bunch of tales from my past, I bring you a condensed history of my work experience: three and a half decades’ worth. I think you’ll be able to relate to how we all interact and work together on a day-to-day basis.

Early periods of isolation

In 1982, I was hired by the University of Maryland Central Administration (UMCA) as a “student programmer” for minimum wage — $3.25 per hour at the time. I found myself sitting in what was once a vending machine closet alongside another student programmer named Chris.

Too green to know how to take advantage of the proximity to someone else, I squandered my social time with Chris discussing things like music and movies. Chris worked on his software only, and I on mine. I don’t recall a single time across my three years at UMCA where we dug deep into each others’ code to learn or help out.

I moved to another tight-but-isolated work environment at the Federal Energy Regulatory Commission (FERC) in Washington, D.C., where I shared an office with two heavy smokers. (Yes, in 1985, you could light up all day.) Doug chain-smoked unfiltered cigarettes, and the elder Jay puffed on a pipe. My attempts at programming sessions were interrupted by the sound of Jay smacking his pants after ash had burned a hole into them.

The accounting system used by the FERC was convoluted, and the software naturally followed form. I was tasked with calculating interest due to the federal government for headwater benefits, because apparently most of the folks running hydropower projects weren’t paying up.

My task should have been straightforward. Unfortunately, no one was able to explain exactly what I was supposed to do — neither Jay, Doug, my manager, nor anyone else in the vicinity understood the complex accounting rules. I wallowed through the code and eventually got something running, at which point my consulting contract ended and it was time to move on. I have no idea whether my software changes were even correct, and I suspect no one else did, either.

It was bizarre to share a physically close environment yet experience almost zero collaboration. But I did get some value out of working in such an isolated fashion: I was learning how to be resourceful. I read manuals cover to cover and started deriving myriad problem-solving techniques.

My next two jobs involved being completely isolated: At both the American Institutes for Research and the Archdiocese of Baltimore, I was the sole programmer reporting to the manager of the computer department. I sat alone and coded by myself for a few years, again honing my survival skills.

The middle years: Cube farms and collaboration

In 1989 I was hired at Marriott in Bethesda, Md., where I was introduced to life in a cube maze. It was nice to be part of a larger team, and it was even better to be working full-time on a software application along with another programmer, Mark. We were both responsible for the development of an accounting system used in airports to support operations for merchandise and food and beverage.

For the first time, I was faced with the direct impact of the crud I coded. Mark and I learned from each other about how to write code that others could more easily understand. I started taking great pride in the quality of my code, often refactoring it for clarity. Mind you, this effort to clean up code that had already been proven to work was highly risky. But I felt the risk was worth it due to the importance of ensuring that Mark and future others could maintain my efforts.

My next cube farm was at MCI in Virginia, starting in 1991. I was now regularly working with a couple of other developers on any given project. We had business analysts and testers. We had a process! I learned object-oriented concepts from my BA (she was once a programmer), client/server architectures from my team lead and coding techniques from my fellow developers.

But the most impressive things I learned while at MCI weren’t technical. And unfortunately, I wasn’t smart enough at the time to heed the first lesson.

Two of the programmers in the group, women from India, had the audacity to sit together throughout the bulk of the day working together. The rest of us didn’t know what to make of it, and at least a couple of folks complained. I mistakenly pooh-poohed the idea myself, figuring that it suggested they hadn’t developed the resourcefulness I’d learned over the prior decade.

Around 1995, MCI shipped me to Atlanta for a few weeks to work on a special project. I was shunted into a dark room, in the center of which were a few tables arranged in an oval, with computers. I shook hands with a few other programmers and got to work.

We actively collaborated with each other throughout the day, initially because we were all tasked with learning the same framework targeted for the application. And once we began development, the heavy interaction didn’t abate; I saw firsthand how constant communication with your team dramatically sped things up. We weren’t wasting time figuring out things others had already mastered. We weren’t preplanning, planning or otherwise sitting in meetings figuring out how we were going to work together. And we weren’t stepping on each others’ toes in the shared codebase.

The increased collaboration in my middle career served me well. Working with others increased my knowledge, helped me understand how my code impacted others and opened my eyes to radically different ways of working.

Interlude: A step backward

Beginning in 1998, I spent two years at a Colorado Springs startup. I was back in a shared office working on something different from my office mate. I immediately felt my choice was poor — why did I accept working in an environment that actively shunned collaboration?

“Actively shunned” is not an exaggeration. When it came time for the engineers to select the office configuration for their high-ceilinged open space, they settled on floor-to-ceiling “cubes” with doors — essentially mini-offices with as much isolation as possible.

Another time, I had a skip-level meeting with a vice president named Fred, who asked what he could help with. I said that things were fine, though my manager was gone often on overnight trips, and I wasn’t sure how to get certain questions answered or roadblocks cleared in his absence. Rather than offer ideas about other channels, Fred instead immediately made me feel stupid for asking the question: “Why can’t you just wait until the next day?” Never mind.

Other events and decisions continued to convince me that the people at this startup felt we should already all know everything. I quickly began to actively seek something better. (Sure enough, the startup folded about a year after I left.)

Moment of enlightenment

Kent Beck, someone whose writings I’d read and enjoyed, was speaking at a Smalltalk conference I attended in 1999. I perused Beck’s sessions in the conference guide and noted one in particular: Extreme Programming. Huh? I had to hear what that was all about.

We’d done spiral development at MCI in the early 1990s and quickly abandoned it — the spiral model’s short iterative, incremental cycles were a great concept, but we couldn’t figure out how to make it really work. Any problems, such as big defects or missed requirements, threatened our ability to finish a cycle within the allotted time; what then?

As a result of my frustration with spiral, most of the talk on Extreme Programming (XP) was an “aha!” moment. Oh! TDD and acceptance testing are how to continually minimize defects. Oh! The planning game is how to negotiate work within a cycle.

The next year, I saw a trade publication classified ad soliciting a consultant, posted by a company named Object Mentor. (I only had a vague idea who its owner Bob Martin was, though I’d actually met and chatted with him at a prior conference.) Noting that the ad was a bit cheeky, I responded in a similar manner, scored an interview and, much to my excitement, was hired. My primary role was to teach customers about Extreme Programming and object-oriented design. Fun!

Pairing: Those who don’t do, teach

While consulting for Object Mentor customers, I found myself in the slightly awkward position of having to promote and teach pair programming. Pairing, where two developers sit side by side and jointly build software, was alien to me; I still thought of it as what those women at MCI did back in 1992. But the more I sat with other developers and helped them through things like test-driven development, the more I started recognizing the very real benefits that pairing can provide.

It wasn’t until after I’d left Object Mentor that I got to experience day-to-day pairing as part of a development team. I spent more than half a year in 2003 building software on a large (17-person!) programming team, all sitting around a large collection of tables. We paired long and hard for 10, sometimes 11 hours.

At the time I found it exhilarating, educational, tiring and sometimes frustrating. The pairing benefits I’d begun to recognize while at Object Mentor were again realized. I also began to pick up more nuggets about increasing pairing effectiveness (for one, 10 hours was very obviously at least a couple hours too many).

On my own as a consultant and trainer from there on out, I’ve continued to pair with customers. Every couple of years, I find a way to minimize travel and focus on just building software as part of a team. This traveling hiatus, in turn, provides me with more chops, which I turn into credibility for my eventual return to consulting and training.

Training: Pairing, randoris and mobs

Ever since creating and teaching most of Object Mentor’s test-driven development (TDD) training material, I’d insisted that students in my classrooms paired during most of their exercises. If I was supposed to be selling pairing, it made no sense to promote something else during training.

In a classroom environment, pairing helps level out everyone’s capabilities. Every class includes at least one stellar performer who completes their exercises well before everyone else. They then often begin to distract others or me, to the detriment of the rest of the class, or they check out entirely.

Just about every class also includes at least one complete novice who is barely able to program. Left to their own devices, they spin wheels. Once I can get around to help them, these novices often suck the majority of my time during exercises, which means other students get short shrift.

Pairing helps even out the rate of development. It also makes it easier for me to spot pairs in trouble. If I see a couple novices working together — the blind leading the blind — I split them up and ensure a seasoned developer works with each.

Some years back, I introduced the concept of a randori-style dojo in smaller classes. A pair of students would initiate a TDD exercise in front of the class, and another programmer would swap into the pair after a few minutes. The randori style keeps the class lively and provides a technique that students can use for entertaining sessions after the class is over.

A bit later, I discovered mob programming. Put simply, mob programming is the utmost in collaboration: The whole team works in the same room in front of a single large monitor. One programmer is at the keyboard listening to the rest of the room — the mob — and translating their directions into computer code. The programmer’s session is typically short, perhaps five or ten minutes, before another programmer takes the keyboard.

With mobbing, developers continually learn from each other and about each other. They dramatically increase their ability to converse about the code at high levels of abstraction. They minimize waste by working on one thing at a time and curtailing ceremony. For these and many other reasons, mob programming streamlines the development process.

Mob teams often tell me, “We go faster.” I believe them. I also find mobbing generally more enjoyable than either pairing or solo development, so it has become my preferred mode.

Although my style of working has gotten increasingly more collaborative over the years, solo programming, pairing, and mobbing each has its place in modern software development. Settling on one mode is likely a mistake. Consider instead that each mode is a tool that should be considered for any given job. It’s up to you how much collaboration is appropriate for your situation and your team.