Two Heads are Better Than One?

Pair programming takes extreme programming to the next level.

• By Mike Gunderloy
• March 01, 2003

Whether you've decided to adapt extreme programming or not, some XP practices are worth investigating. One of these is pair programming, the practice of having two developers work on code simultaneously. Laurie Williams and Robert Kessler have studied Pair Programming extensively, and report their results in Pair Programming Illuminated (Addison-Wesley, 2002). What can you learn from this book?

One Size Fits All?
Advocates of XP tend to believe in absolutes, or at least to make absolute pronouncements. Kent Beck's original book on XP, Extreme Programming Explained (Addison-Wesley, 1999) makes the simple pronouncement:

All production code is written with two people looking at one machine, with one keyboard and one mouse.

That's it. All code. No exceptions. Beck goes on to say that someone who simply refuses to pair is not suited to XP, and should find work with a project using some other methodology.

Of course, if you poke around outside the XP literature, you'll find other people willing to challenge this attitude. One of the bluntest challenges comes from the pseudonymous Rich Camden (http://www.softwarereality.com/lifecycle/xp/xp_trenches.jsp):

This is the worst of the XP tenets. To recommend pair programming across the board for all developers involved in XP is to not understand the people/personality side of programming. Yes, there are those who will benefit from having another programmer constantly sitting over their shoulder assisting and reviewing their work. But, there are many more who will feel uncomfortable and restrained with another programmer watching everything they do. Unfortunately, this tenet above all others tends to dampen creativity and heroics in XP. Many of the best programming gems come after absorbing oneself in a problem, and much deep thinking. This does not occur when you have another programmer looking over your shoulder.

My own take? Pair programming is not for everyone, but many of those who think it's not for them simply haven't tried it (this doesn't apply to Mr. Camden, whose critique of XP is worth reading in its entirety). Programmers tend to have healthy egos (how could it be otherwise, when we create value from thin air by the sweat of our brows?) and it's hard for us to admit that we could use a little help in our chosen profession.

If you think you're not suited for pair programming or that it won't work on your project, my advice is to try it. These days, living out on the farm in the middle of nowhere, I don't get a lot of chances to pair. But many of my most productive development days in the past have been spent pair programming (and the bulk of those before XP hit the scene; this is not all that new an idea). Done properly, pair programming becomes an exercise in division of labor. The active partner can concentrate on code syntax and the micro-level issues of "what comes next?" The navigator can concentrate on strategic thinking, instant code reviews, and thinking about alternatives. It really does work. At least, it has for me. I've come in as the hotshot programmer who's going to save the day on more than one project, but I've yet to find another developer who couldn't teach me something when we worked together.

The Economic Argument
Williams and Kessler start their book by discussing some of the pros and cons of pair programming. Perhaps not surprisingly, they find mostly pros. They also devote a chapter to overcoming management resistance to pair programming. Although it's counterintuitive, they marshal a reasonable number of studies to suggest that developing code with pair programming takes the same number of man-hours as it does without, or perhaps a bit more. More important, the pair-programmed code tends to be shorter—and to have fewer defects—than more traditionally developed code. The authors make the economic argument that it's worth investing the estimated 15 percent more time up front, because it's more than made up for by decreased maintenance costs later in the software lifecycle.

Is this a reasonable argument? Perhaps. Software development is one of those fields where you can by now find studies to prove (or at least suggest) nearly anything. Certainly there are cases where pair programming saved time and money. One has to wonder just how general the results are—the studies I've seen tend to be as anecdotal as scientific, the numbers they're putting out are hard to measure, and the sample sizes are small. My own feeling is that pair programming is economically beneficial some of the time, and that we don't quite know enough to define that time yet.

But there are certainly other reasons to consider this strategy for software development. Among the reasons the authors enumerate:

• Pair programming diffuses knowledge among the group, increasing the critical "truck number" (the number of developers who would have to be hit by a truck to incapacitate the project).
• Employees tend to be happier, which keeps them on the job longer (and some managers even see happy employees as a goal in itself).
• Training costs are reduced when new employees are paired with experienced ones.
• Communication between team members is increased, which leads to fewer code defects caused by conflicting assumptions.

One caveat to the economic argument, though: there's some evidence that paired programmers work more efficiently because they're actually working. That is, while an individual developer might make time to check e-mail, surf the web, pay bills at his desk, and munch on fudge while strumming a banjo (this is generally called "planning the next module"), most of us are reluctant to do these things when we're working with another developer at the same desk. There might be some long-term quality of life consequences as a result.

Tricks of the Trade
A large chunk of the book is devoted to looking at some of the practical issues of pair programming, and how to use the technique effectively in various circumstances. These include such scenarios as:

• An expert paired with a novice
• An introvert paired with an extrovert
• A partner who refuses to let the other member of the pair drive
• Gender and culture conflicts
• Issues of too little or too much ego

Some of this part of the book takes on an almost pollyannaish tone, as the authors are able to squeeze good things out of almost any situation, or at least find a way around it. Take the "professional driver" who won't give up the keyboard. At their most positive, Williams and Kessler suggest that such a person might benefit from watching an effective pair at work, and pick up the good habits that pair demonstrates (trading typing duties is one of the core notions of pair programming). But they also pass along a variety of other suggestions that the ignored navigator can follow to take control of the keyboard, including bringing lots of coffee to the driver and then grabbing the machine during the inevitable bathroom break.

Treat this section of the book as source material for brainstorming, and you'll probably find that it serves you well, both in identifying potential trouble patterns and in pointing the way to solutions.

Also useful to many people will be the pair programming tutorial appendix, which contains a series of exercises designed to introduce teams to the look and feel of pair programming. This three-hour workshop has lots of ideas to get you and your team started.

Buy It?
That's really two questions, not one: Should you buy into pair programming? And should you buy this book to help you? I'll tackle them in reverse.

At $35 for under 300 pages, this might seem like a fairly pricey book. But think about the costs of developer time. If you end up saving half an hour of your own time, or five minutes of a five-person team's time, then it's already paid for itself. If you're even remotely considering pair programming, I'd go ahead and buy this one (and, if you don't already have it, Kent Beck's book too) and set aside the time to read it. You'll probably pick up enough tips to make it worth the money. Or you may decide that the descriptions here don't sound at all like your team, and you don't even want to try pair programming—which would be another good use of the money.

But should you try pair programming? I believe the answer to that question is a qualified "yes." If you can get support from management, then it's definitely worth experimenting with pair programming to find out whether it's a good fit for your team and your project. Support in this case may mean a temporary relaxation of reporting requirements, permission to move computers out of the cubicles and into the lounge, or a bit of budget for a training session. Or it may mean that they look the other way while you carry out a classic "skunk works" exercise of working behind management's back. All I know is that as a developer, I personally like working this way. And as a development manager, I like the benefits of happier, more productive employees. Sounds like a win to me.

Have you ever tried pair programming? Was it the greatest thing since sliced bread, or did you flee back to your own cubicle? Write and let me know. I'll use the most interesting comments in a future issue of Developer Central.