Pair Programming Misconceptions
Pair Programming MisconceptionsThere are several common misconceptions about PairProgramming.
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.
I can get the same results without pairing.
Pairing creates a unique environment for creativity. Creativity, unlike IQ, is not something mainly determined by an individual. It comes from collaboration. A surprising large amount of creativity comes when someone repeats back your ideas to you. (A great example of this is from WardCunningham, inventor of the Wiki & Fit, but not Fitnesse (a wiki based version of Fit) which was a natural creative step when BobMartin heard about it)
The nature of creativity is talked about in depth in Group Genius by Keith Sawyer (which doesn't explorer pair programming at all to my dismay) but let me summarize the most important part. When faced with a problem like: Connect the dots using only 4 lines and without lifting your pencil.
. . . . . . . . .People will think of a possible solution. Try it. If it fails they will try a variation of it, and repeat. This is how humans think! The problem occurs when the initial path will not lead to a solution. Then you need to think outside the box, or Creatively. But our brains don't do that, so what happens is we go home, or out to a bar, or on vacation, and our brains forget about the path, but see something else and then start trying those variations a new path. This is why we see so many creative solutions on a napkin, or in the shower. Our minds where able to try a new path.
However, when you collaborate with others you are constantly being put on new paths. Interaction with other people starts to push you on to other paths and those paths push the other person to still other paths. Creativity is massively enhanced.
So the next question is:
Do you consider programming to be a creative process?
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
Yes, I got warts off my pair programming partner. I highly recommend not sharing keyboard with someone who has them on their hands.
EditText of this page
(last edited March 18, 2012)
or FindPage with title or text search