Collective Wisdom from the Experts 171
Pair programming is popular with, though not exclusive to, proponents of
agile software development. Some who object to pairing ask, “Why should I
pay two programmers to do the work of one?” My response is that, indeed,
you should not. I argue that pairing increases quality, understanding of the
domain and technology, and techniques (like IDE tricks), and mitigates the
impact of lottery risk (one of your expert developers wins the lottery and
quits the next day).
What is the long-term value of learning a new keyboard shortcut? How do we
measure the overall quality improvement to the product resulting from pairing?
How do we measure the impact of your partner not letting you pursue a dead-
end approach to solving a difficult problem? One study cites an increase of 40%
in effectiveness and speed.* What is the value of mitigating your “lottery risk”?
Most of these gains are difficult to measure.
Who should pair with whom? If you’re new to the team, it’s important to find
a team member who is knowledgeable. Just as important, find someone who
has good interpersonal and coaching skills. If you don’t have much domain
experience, pair with a team member who is an expert in the domain.
If you are not convinced, experiment: collaborate with your colleagues. Pair on
an interesting, gnarly problem. See how it feels. Try it a few times.
*. T. Nosek, “The Case for Collaborative Programming,” J Communications of the ACM, March 1998