- 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.
Community comments
"if the code is boring, maybe the design is bad"
by Jean Barbu,
What about pair programming where only one half is a programmer?
by James Taylor,
"if the code is boring, maybe the design is bad"
by Jean Barbu,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not 100% true. Try developing any nowadays web application UI when selecting a radio button should display new 10 controls, disable other 5 and hides the rest of it. Find that challenging?
What about pair programming where only one half is a programmer?
by James Taylor,
Your message is awaiting moderation. Thank you for participating in the discussion.
How about using a business rules management approach and having a programmer and a business analyst be the pair developing the "code"? Lots of business rules customers do that and get great results - the business person understands the problem, the programmer has the technical skills to understand the objects involved and performance implications and they turn out a lot of accurate rules quickly.
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
JT www.edmblog.com