Two Heads are Better Than One?
Pair programming takes extreme programming to the next level.
Two Strings to his Bow (He has).: He is provided against contingencies;
if one business of adventure should fail, he has another in reserve; two
sweet-hearts, two devices, etc.
—Brewer's Dictionary of
Phrase and Fable (1898)
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.
About the Author
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.