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?  

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