Chapter 4. Pair Programming: Why Have Two Do the Work of One?

Laurie Williams

As a head of the team, I initially thought that we might be wasting human resources by having two engineers do the work of one. Moreover, I thought, they'll be chatting and giggling more than working. "Too many cooks spoil the broth," you know. Though I agreed that there would be fewer syntax errors, I could not comprehend their timesaving effect. To be frank, quite like everyone else in the team, I did not appreciate the idea. And you know how difficult it was initially to get going with it! But as we delved deeper into the project, I realized that it gave us fewer errors, no slippage, and more than everything … team strength and companionship.

Development manager at a technology corporation in India

Pair programming is a style of programming in which two programmers work side by side at one computer, continually collaborating on the same design, algorithm, code, or test. One of the pair, called the driver, is typing at the computer or writing down a design. The other partner, called the navigator, has many jobs. One is to observe the work of the driver looking for tactical and strategic defects in the work of the driver. Tactical defects are syntax errors, typos, calling the wrong method, and so on. Strategic defects occur when the driver is headed down the wrong path what they are implementing just won't accomplish what it needs to accomplish. The navigator is the objective, strategic, longer-range thinker. Any of us can be guilty of straying off the path. A simple "Can you explain what you're doing?" from the navigator can serve to bring us back to earth. The navigator has a much more objective point of view and can think better strategically about the direction of the work. One great thing is that the driver and the navigator can brainstorm on demand at any time. An effective pair programming relationship is very active. The driver and the navigator communicate at least every 45 seconds to a minute. It is also very important to switch roles periodically.

Anecdotal and statistical evidence indicates many benefits of pair programming. These benefits are described in this chapter. However, without a doubt, there is resistance to transitioning to pair programming. One group of people who resist is managers. They often have the knee-jerk reaction "Why in the world would I pay two programmers to do something that one programmer could do?" This is not a surprising reaction. This chapter addresses the concerns of managers who are considering or are resistant to transitioning to pair programming. Specifically, we examine five common motivations of managers that pair programming can address [Williams+2002].