Common misconceptions about paired programming

Paired programming is an agile practice that is the source of much debate. Martin Fowler, one of the signatories of the Agile Alliance and well known author and thought leader, has written an article on common misconceptions with paired programming.  The misconceptions, in brief summary, are:

• Doing Agile requires doing pair programming.  "The manifesto doesn't mention pair programming and most agile methods don't make it part of their approach."
  
• XP requires pair programming. XP projects usually do XP but "like any agile method, expects a team to choose its own process."
  
• People assuming they just won't like pair programming. Most people like it after they try it, others don't do it right and are left with a false impression.
  
• Pair-Programming halves the productivity of developers.  Better designs, less mistakes, better understanding offsets the decrease in ability to type code.
  
• It's only worth pairing on complex code, not boring rote code. Martin mostly agrees with this but points out that if the code is boring, maybe the design is bad. :)
  

On the point about halving productivity, Alistair Cockburn & Laurie Williams' XP2000 paper on the cost and benefits of pair programming concluded that together pairs spent 15% more time on a problem together than apart, but this is "repaid in shorter and less expensive testing, quality assurance, and field support."  Another empiracle study which included Ward Cunningham and Ron Jeffries showed that by the third pairing attempt,  paired programmers were producing 19% better code for only 10% more programmer-hours.

Ward Cunningham's famous C2 wiki also includes a pair programming page with another set of misconceptions:

• Pairing is primarily a micro-level source code review.
• Pairing will halve my team's productivity (same as Martin's).
• Pairing sounds like an unpleasant task. It would drive me crazy (same as Martins).
• We don't do pair programming here.  But infact people often get together to solve bugs which is a form of pair programming.
• Pair programming is a training program.

Martin's write-up included an important lesson, which is a good one for all of us:

I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective.