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 href="">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”: style="mso-spacerun: yes">  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. style="mso-spacerun: yes">  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. style="MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: list .5in">Improved
    code quality: 

    1. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: list 1.0in">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. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: list 1.0in">Less
      trivial bugs

    3. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: list 1.0in">When
      the active developer started tiring, the pair swapped roles so that the
      person writing code was always sharp and focused.

  2. style="MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: list .5in">Improved
    team performance: 

    1. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo2; tab-stops: list 1.0in">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. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo2; tab-stops: list 1.0in">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

    3. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo2; tab-stops: list 1.0in">The
      entire team was always on the same mental wavelength with virtually no
      communication issues.

  1. style="MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo2; tab-stops: list .5in">Improved
    personal development

    1. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo3; tab-stops: list 1.0in">Pair
      programming creates ongoing knowledge transfer, whenever someone learned
      something new it was quickly known by everyone.

    2. style="MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo3; tab-stops: list 1.0in">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
measurably reduce the development time of projects, and probably even
increased it.   But looking at
the bottom line, even though projects were not style="mso-bidi-font-style: normal">written faster, they were style="mso-bidi-font-style: normal">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:

  1. style="MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: list .5in">Formally
    define the roles of the “active” and “passive”. Pairing isn’t about 2 guys
    sharing a keyboard.

  2. style="MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: list .5in">Never
    pair up 2 people with the same level of experience.

  3. style="MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: list .5in">Swap
    pairs periodically.

style="MARGIN: 0in 0in 0pt">     

So, that was my long, rambling
$0.02 on the topic of pair programming style="FONT-FAMILY: Wingdings; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'; mso-char-type: symbol; mso-symbol-font-family: Wingdings"> style="mso-char-type: symbol; mso-symbol-font-family: Wingdings">J

style="MARGIN: 0in 0in 0pt"> 

Comments (5)
  1. Jeff says:

    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.

  2. Addy Santo says:

    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.

  3. Jeff says:

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

  4. Steve Hall says:

    Addy: You’re quite right about pair programming not being a recent invention….rather a pretty old one. It was born in the early 50’s and 60’s out of neccessity: programmers HAD to share computer terminals, as 3270’s (and full-duplex ASCII displays) cost far more than several modern PCs. Back then, this was called "shared programming", "shared terminal programming", then finally "paired programming" (if you found two programmers that could get along with each other). (BTW, 3270 displays in the late ’60s cost well over $10K…while in 1970 dollars a cheap $2000 PC would have cost around $300-400.)

    Back then, when you interviewed at a "computer site" you hoped to walk past the terminal room, so you could figure out the terminal-to-programmer ratio. If it was less than 3 or 4 to one, it was considered a great place to work. And if the staff programmer interviewing you had their own 3270 or ASCII hardcopy terminal, then you’d kill to work there! (Even if you DID have to work there 10 years before getting your own!)

    The advent of PCs virtually put an end to "terminal rooms" (which typically had twice the number of chairs as terminals) and put pair programming "on ice" until it was rediscovered recently.

    My experiences of only mid-career being "nice enough" to pair up at terminals was from that era, but amazingly I haven’t seen it change any over the following three decades. I think it’s due to PCs being so cheap, and junior programmers and staff programmers feeling a bit aghast at the idea of not being allowed to be left alone to their own devices….(sic)

    The one technique you list of making pair programming work is the EXACT reason why the name changed from "shared programming": one programmer letting the other "drive" the keyboard, and relegating themself as the "backseat driver". That is why I believe only mid-career programmers are successful at it: they’re past the arrogance of early youth, but not yet a master of the arts…….and more concerned about getting their ideas used, then being a "code monkey".

    Interestingly, one may assume the person at the keyboard is the master. Contrary to that, how often have you seen presenters during keynote speeches (as at TechEd or PDC) refer to their keyboard partners as "my code monkey!"…i.e., slave…and that code monkey NOT being allowed to contribute much to the functionality, rather only the operational aspects of the code?

    Essentially, it’s just like sex: being passive or active doesn’t infer being on top or bottom. "Coders" (junior programmers) quite often don’t get this distinction: that the coding isn’t as important as the thinking. (Staff programmers have the opposite problem: they know the difference, but just want to have sex with themselves! Usually ’cause they’re secretly in love with their own largeness of talent.)

    Most good programmers 2-3 decades ago figured this out, and allowed the "weaker" of the pair to THINK he was the master by being at the keyboard. (Usually, by the time the passive keyboarder figured it out, they wouldn’t complain too much…as they were learning a LOT by being passive…even though they were doing all the typing!)

    Whenever I had a keyboard slave whine about "doing all the hard work", my response was (and still is), "If you give me that keyboard, then I will do it ALL MYSELF!" Usually, they would see their short career flash before their eyes, and continue typing… (But, to balance out my own largeness of talent, I usually tell them that for every BIG BUG they find that can be blamed on me, they get a free lunch.)

Comments are closed.

Skip to main content