Common misconceptions about paired programming
- 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. :)
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.
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.
"if the code is boring, maybe the design is bad"
What about pair programming where only one half is a programmer?
I wrote an article about rules and agile but for some reason did not mention this scenario. I also wrote a piece on how rules close the gap between IT and the business here on my blog. Would love to know what people think