Pairing is primarily a micro-level source code review.
Pairing is primarily about establishing a shared MentalStateCalledFlow. Flow is the deep-thinking state where most hard problems fall. Most programmers have only ever experienced flow in quiet solitude, so they assume that you could never get there while interacting with someone else. But you can, as long as you are both focused on the same problem.
The hardest thing about pairing for some is holding one's tongue for a few seconds when their partner creates a syntax error. Usually, they've already seen it too, and are about to back up and fix it. Speaking up too soon can diminish flow.
Pairing will halve my team's productivity.
This assumes that typing speed is the bottleneck for programming. Is this really your experience, and if it is, why aren't you sending all your programmers to mandatory typing classes?
The only empirical study on pairing that we've seen (http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF) shows that by the third pairing attempt, pairs were producing 19% better code for only 10% more programmer-hours.
(Please include more data if found.)
If you're a true XP team in all other respects, it should be easy to get empirical data of your own. Just don't pair for one iteration, and see what happens to your velocity. You'll have hard data in 3 weeks or less.
Pairing sounds like an unpleasant task. It would drive me crazy.
Try it. Yes, it will be awkward and hard at first, but you and your partner will learn to work together. You'll produce more in less time. You'll stay focused on the job at hand. You won't get stuck by small oversights. You'll hardly have writers block, because you have someone right there that you're bouncing ideas off. You'll learn a lot as you go because you'll learn your partner's insights as well as ones that you discover. Together you'll be doing better than either of you would have done solo. Once you two get in the groove, you'll rock! It feels good to be good at your job. Many people have a blast pairing.
I've paired with Java newbies up to people who were at least as good as I am. I always learn something, and I never feel like I'm carrying the other person. If I could, I'd only ever do pair programming, just for the fun of it. -- JohnBrewer
People who say this could probably benefit from this RonJeffries quote:
We don't do pair programming here.
Many shops use pair programming. It's just called something like working on a really hard bug. Most of the time, one developer will get together with another developer to work on the hard bug, they'll solve it (having a great time, by the way), and then they'll slink guiltily back to their respective offices, since they know programming is supposed to be a solitary activity.
XP has just given a name to this furtive practice, and let it out into the sunshine for the first time.
Pair programming is a training program.
A pair programming relationship is about working together to produce a better result not about one person showing another how something must be done. It is usually the case that both members of a pair relationship will learn some new things. A dominate teacher and subordinate student relationship is not what pair programming is about. Two people of equal though different abilities work together and produce a better product.
People often wonder what a newbie can contribute to a pair relationship with someone who has been developing good software for many years. Wouldn't it be better to let the experienced person code by himself most of the time instead of having to always be training someone? No. Everyone has something to contribute.
One of the things I cherish most about pair programming with someone much younger than me is that enthusiasm. I have become calm, steady, and consistent in my old age. Pair me up with someone young who wants to turn the world up side down and stand back, way back!!!
You can catch social diseases through pair programming.
Like enthusiasm? ... or is someone fishing for a pun on "mis-conceptions?" --EricHerman
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006