Share via

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

Comments

  • Anonymous
    June 04, 2004
    I'm honestly not a big fan of pairs. When it comes to more complex things, having a backseat driver is outright annoying, and it's worse if there's a big difference in ability.

    In fact, I've found that the "benefit" of a second person in a test-driven development scenario is little to none, provided you have good code coverage.
  • Anonymous
    June 04, 2004
    Just to set things in context: I'm advocating the advantages of PP to the "average" development team.

    The top 5% of developers - the ones who can take an app from envisioning through deployment by themselves and have done so 20 times already - don't really need PP. But on the other hand, they don't really need anything else either, stick em in a cave with notepad and some dr. pepper and they are set to go.

    Your comments can co-exist quite peacefully with mine :) But if you ever need to take 5-10 less experienced developers and wring every last bit of productivity out of them - PP is definitely worth considering.
  • Anonymous
    June 04, 2004
    Brings back my early days of programming COBOL back in the 80's.

    My "active" had scads of experience coding and I was the newbie as far as COBOL goes.

    But I found within a few weeks we were switching rolls every few hours during the day. We had a great time, some laughs and some disagreements. All in all, it was a superb experience for me and it helped me greatly.

    Thanks for this article. Your advice paired my memories of this to a "T".
  • Anonymous
    June 05, 2004
    The comment has been removed
  • Anonymous
    June 14, 2009
    PingBack from http://adirondackchairshub.info/story.php?id=1373