Developing In Pairs

Randy and I work on a software tool together. Over the years that we have developed it, we have found that we spend a lot of time at each other's desks. We often write code, debug, and test together. It is not uncommon for one of us to be typing, while the other one tells what to type. And often, the one not typing will point out typos or logic errors. That can be annoying, but it certainly reduces the cycles of compiling and debugging.

Nobody told us to work this way. We just found that it works well.

...a development organization is in place, and people have started to commit to work and are about to start building the work artifacts. Some of the work may be allocated on the basis of CodeOwnership. There is enough understanding about overall requirements to start work, though many requirements may have loose ends.

✥ ✥ ✥

Some people don't want to work alone, and working alone has great risks of blindsiding and misfits. And you need to provide for people who don't want to work alone, and in general engage people who are working alone but probably shouldn't be.

People sometime feel they can solve a problem only if they have help. Some problems are bigger than an individual, so even people who are comfortable working alone should work closely with someone else who at least provides another set of eyes to look over the work. 

It takes extra resources to do this in real time; one might argue that code walk-throughs and inspections and reviews are enough to compensate for these problems. But these reviews are usually analytical rather than opportunistic. And reviews set up an adversarial context where the critics don't have the same stake as the programmers. And reviews catch problems after the programmer has committed to the corresponding structures and algorithms and expended a lot of effort in elaborating them, rather than stopping them at the conceptual stage. And many of these decisions are too detailed to arise in design reviews or simply can't be foreseen until the programmer grapples with implementation, yet are weighty enough that they might threaten the viability and long-term health of the code. 

Only a limited number of people can sit in front of a keyboard and screen. Communication and coordination effort increase nonlinearly with number of people. So you can't always create a team that works together as a unit to contribute to an artifact in front of a single screen. 

Therefore: 

Pair compatible designers to work together; together, they can produce more than the sum of the two individually.

There are two keys to making this successful. First, the individuals must be able to work well together. This means that pair assignments must not be made arbitrarily. In fact, because a pair is in reality a small team, SelfSelectingTeam must be applied. The chief consideration for creating a pair is that the two want to work together. 

Second, the style of pair development must not be dictated; it should be left up to the individuals. Simply put, there should not be a rule that no line of code is written unless both people are at the keyboard. Instead, give the pair the assignment, and let them figure out how to do the development. Note that this practice supports FeatureAssignment. 

The pair needn't always comprise developers only. In BuildPrototypes, and in many other activities, one of the pair can be a customer, systems engineer, or technologist representing an area of risk being explored by the prototype. At Mediagenix, a tester sometimes pairs with a developer as the tester drives with tests, and the developer fixes bugs. This makes it possible to circumvent the project's formal bug reporting bureaucracy, reducing the time to a stable load (see also CouplingDecreasesLatency). 

✥ ✥ ✥

Overall, this leads to a more effective implementation process. Experience has shown that, contrary to simplistic reasoning, it may cost less overall to program in pairs than to have one coder work on code at a time. In an analogous study, it was just found that it actually saves money in a hospital to have a pharmacist follow doctors on their rounds as they make prescriptions. The pharmacist's insights in correcting the doctor's errors (e.g., prescribing drugs that are incompatible with each other) saved more money (in additional health costs) than the pharmacist cost; plus, it capitalized on the pharmacist's dead time between activities. 

A pair of people is less likely to be blindsided than an individual developer. 

You help ensure that SomeoneAlwaysMakesProgress. 

If enough people use DevelopingInPairs, and if the pairs rotate occasionally, you get an emergent structure and emergent organizational behavior that contributes to cross-training, information sharing, and trust. 

Compare this pattern with GroupValidation and ResponsibilitiesEngage. One special case of DevelopingInPairs occurs when one developer asks another developer (or other suitable expert) do a desk check of recently written code. This is much less costly and not less effective than the traditional code inspections, code walkthroughs, and code reviews. Though probably less effective than the "canonical" form of DevelopingInPairs, its worth has empirically been validated [BibRef-Votta1993]. 

There are other configurations which have much of the dynamics of DevelopingInPairs but which are not strictly just a dynamic duo. At Mediagenix we found teams that "programmed with the projector" where the computer screen was projected onto a wall, and a team jointly commented and guided the work as one person sat at the keyboard. In Bell Laboratories, Joe Davison, Ricky Spiece and Martin Biernat worked on a team with one at the white board, one at the terminal "thinking out loud" and representing the customer. In this case, the code was written on the board, transcribed into the computer (in Smalltalk) and the third person did a real-time code review. 

And in what might be viewed as another slant on pair programming, Doug Lea used a variant of the clean room methodology that employed a single programmer: once in a role as programmer, and once in a role as tester. Clean room techniques separate these two roles to make sure one's knowledge doesn't unduly influence the assumptions of the other. In the extreme application of clean room, developers are not allowed to use the compiler to check their own code, but await such feedback from the tester. Doug mimicked this behavior by wearing two hats. In one sense, this is as unlike popular pair programming as one can get: each "side" of Doug worked in isolation. But the interplay between the two perspectives was where the power lies: bringing multiple perspectives to bear on the same artifact with tight coupling of minds. Doug's mind provided the tight coupling.