Pairing mechanics
Pairing involves having two programmers working at a single workstation. One programmer “drives,” operating the keyboard, while the other “navigates,” watching, learning, asking, talking, and making suggestions. In theory, the driver focuses on the code at hand: the syntax, semantics, and algorithm. The navigator focuses less on that, and more on a level of abstraction higher: the test they are trying to get to pass, the technical task to be delivered next, the time elapsed since all the tests were run, the time elapsed since the last repository commit, and the quality of the overall design. The theory is that pairing results in better designs, fewer bugs, and much better spread of knowledge across a development team, and therefore more functionality per unit time, measured over the long term.
Spreading knowledge
Certainly as a mentoring mechanism, pairing is hard to beat. If pairs switch off regularly (as they should), pairing spreads several kinds of knowledge throughout the team with great efficiency: codebase knowledge, design and architectural knowledge, feature and problem domain knowledge, language knowledge, development platform knowledge, framework and tool knowledge, refactoring knowledge, and testing knowledge. There is not much debate that pairing spreads these kinds of knowledge better than traditional code reviews and less formal methods. So what productivity penalty, if any, do you pay for spreading knowledge so well?
Pairing and productivity
Research results and anecdotal reports seem to show that short-term productivity might decrease modestly (about 15%), but because the code produced is so much better, long-term productivity goes up. And certainly it depends on how you measure productivity, and over what term. In an agile context, productivity is often measured in running, tested features actually delivered per iteration and per release. If a team measures productivity in lines of code per week, they may indeed find that pairing causes this to drop (and if that means fewer lines of code per running, tested feature, that’s a good thing!).
Productivity and staff turnover
Proponents of pairing claim that if you measure productivity across a long enough term to include staff being hired and leaving, pairing starts to show even more value. In many mainstream projects, expertise tends to accumulate in “islands of knowledge.” Individual programmers tend to know lots of important things that the other programmers do not know as well. If any of these islands leaves the team, the project may be delayed badly or worse. Part of the theory of pairing is that by spreading many kinds of knowledge so widely within a team, management reduces their exposure to this constant threat of staff turnover. In extreme programming (XP), they speak of the truck number: the number of team members that would need to be hit by a truck to kill the project. XP projects strive to keep the truck number as close as possible to the total team size. If someone leaves, there are usually several others to take his or her place. It’s not that there is no specialization, but certainly everyone knows more about all of what is going on. If you measure productivity in terms of features delivered over several releases by such a team, it should be higher than if pairing does not occur.
Pairing strategies
In by-the-book XP, all production code is written by pairs. Many non-XP agile teams do not use pairing at all. But there is a lot of middle ground between no pairing and everyone pairing all the time. Try using pairing when mentoring new hires, for extremely high-risk tasks, at the start of a new project when the design is new, when adopting a new technology, or on a rotating monthly or weekly basis. Programmers who prefer to pair might be allowed to, while those who do not are allowed not to. The decision to use code reviews instead of any pairing at all is popular, but we don’t know of any reason not to at least experiment with pairing. There is no reasonable evidence that it hurts a team or a project, and there is increasing evidence that it is a helpful best practice.
