Pair-Programming - Necessary?

  • Article

Roy
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
produced. 

 

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
everyone else.

 

As I said, I liked PP because of
the results. Those were:

 

  1. Improved
    code quality: 
    1. Having
      two sets of eyeballs focused on the code at all times reduced the need for
      code reviews since the code was simply better.
    2. Less
      trivial bugs
    3. When
      the active developer started tiring, the pair swapped roles so that the
      person writing code was always sharp and focused.
  2. Improved
    team performance: 
    1. Team
      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.
    2. We
      could easily load-balance internally since the all the team members were
      comfortable with all the code (hence *most* the dev tasks) in the
      system.
    3. The
      entire team was always on the same mental wavelength with virtually no
      communication issues.

  2. Improved
    personal development

    1. Pair
      programming creates ongoing knowledge transfer, whenever someone learned
      something new it was quickly known by everyone.
    2. All
      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
      experienced members.

 

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
teams.

 

My advice to people beginning
with Pair Programming:

  1. Formally
    define the roles of the “active” and “passive”. Pairing isn’t about 2 guys
    sharing a keyboard.
  2. Never
    pair up 2 people with the same level of experience.
  3. Swap
    pairs periodically.

     

So, that was my long, rambling
$0.02 on the topic of pair programming J