Pair-Programming - Necessary?
mentions pair-programming and a situation in which a pair fell apart because "it
just seemed unnecessary" to the developers. There is an interesting comment
thread developing there, but the post begets the question - why is it
necessary? "urn:schemas-microsoft-com:office:office" />
Many people seem to think that pair programming is a new idea and is somehow
tied in to XP, TDD or other "new & radical" methodologies. The truth is that
pair programming has been around for a very long time. Frederick Brooks
discusses it in The
Mythical Man-Month, an amazing, timeless book which is as relevant
today as it was 30 years ago.
As the dev lead and later CTO of
a software firm, I found myself using team programming quite often, not out of
“beliefs” in any specific methodology but instead based on the good results it
Before discussing the results,
let me explain my interpretation of “pair programming”: One developer (the “active”) is at the
keyboard writing the code, focused on the gory details of the implementation;
the next line, the next loop, the next method. The other developer (the “passive”)
shadows the first while thinking a step ahead (is this adhering to the
design? Could we reuse any of our
existing code or design patterns here? How will it perform?) And while thinking,
the passive is following the evolution of the code, keeping the active developer
honest and catching trivial mistakes: “Hey, you forgot to handle null return
values”. We swapped pairs often so that everyone on the team worked with
As I said, I liked PP because of
the results. Those were:
two sets of eyeballs focused on the code at all times reduced the need for
code reviews since the code was simply better.
the active developer started tiring, the pair swapped roles so that the
person writing code was always sharp and focused.
members had the confidence to change any part of the system without the “I
didn’t write it so I’m scared of breaking it” syndrome.
could easily load-balance internally since the all the team members were
comfortable with all the code (hence *most* the dev tasks) in the
entire team was always on the same mental wavelength with virtually no
programming creates ongoing knowledge transfer, whenever someone learned
something new it was quickly known by everyone.
developers had the chance to experience both roles (active/passive) and also
compare themselves to their peers. This was a real eye opener for the less
The downside is that it did
not measurably reduce the development time of projects, and probably even
increased it. But looking at
the bottom line, even though projects were not written faster, they were completed faster due to the fact that
the code was more stable and could actually be released with the allotted QA
time (which was never enough).
And to me as the Lead Dev, I got
what I really wanted: Professional,
productive developers with high morale working in efficient and independent
My advice to people beginning
with Pair Programming:
define the roles of the “active” and “passive”. Pairing isn’t about 2 guys
sharing a keyboard.
pair up 2 people with the same level of experience.
So, that was my long, rambling
$0.02 on the topic of pair programming J