Common misconceptions about paired programming
- Share
-
- |
Read later
My Reading List
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:
Ward Cunningham's famous C2 wiki also includes a pair programming page with another set of misconceptions:
2 comments
- 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.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Community comments
"if the code is boring, maybe the design is bad"
by
Jean Barbu
Posted
What about pair programming where only one half is a programmer?
by
James Taylor
Posted
"if the code is boring, maybe the design is bad"
by
Jean Barbu
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
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
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
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think