Why Pair Programming Works
Pair programming is like magic in more ways than one. It dramatically improves programmer productivity and reduces bug count, and yet it does so through a technique that’s completely counter-intuitive. You can’t help but think that there’s some trick yet to be exposed; that pair programming is just slight of hand. In this article, I will endeavor to pull back the curtain and reveal the secrets of the pair programming magicians.
Specifically, I identify six reasons pair programming succeeds:
- Continuous Code Review
- Fewer blockages
- Masking distractions
- Guaranteed focus
- Multiple points of view
- Reduced training cost and time
Continuous Code Review
One of the maxims of extreme programming (XP) is to turn all the dials to 11. Code review is good, so continuous, instantaneous code review is great; and that’s exactly what pair programming delivers. No more back and forth over a week. No more waiting for feedback on a code review. Instead, feedback comes immediately. This means less time waiting for reviews and less time going down the wrong path. The time savings compared to classic code reviews is dramatic. In fact, this savings alone is likely to pay the cost of pair programming.
Furthermore the feedback is more likely to be useful that that from classic code reviews. When presented with a 60 file change list, the tendency for most reviewers is either to give it a perfunctory once over, or to merely focus on the little details like indentation without really seeing the bigger picture. However, when pair programming, both developers are actively involved with the code and can see what’s happening as it happens. Code reviews start and continue one line at a time and grow gradually with the code. It’s much easier to understand code this way than by having 60 classes and 3000 new lines of code dumped on you in one huge batch.
Finally, feedback can be incorporated more quickly and easily when it’s given earlier in the process. It’s bad enough having to review 60 classes and 3000 new lines of code. It’s much worse having to throw all that code away after a month’s work and start over because the reviewer has uncovered a serious design flaw. The sooner the flaws are noticed, the cheaper they are to fix. Pair programming is much less likely to produce misguided code.
And if you’re not already doing code reviews? Then introducing them through pair programming is going to improve your code quality and programming velocity that much more.
Fewer blockages
We’ve all experienced the annoying bug that just won’t die, no matter what we try. Sometimes we work on it for a day and then immediately see the answer when we wake up the next morning. Sometimes we work on it for two days or more until we finally break down and ask for help, at which point our cube mate says, “Oh, you’re implementing getProjectId() when you should be overriding getProjectID().”
Why wait?
Stupid bugs like these waste a lot of time; but blind spots are rarely shared. What one programmer doesn’t see, the other one likely does. Find one of these per day by pair programming, and you’ve paid for the extra pair of eyes. You may not even realize how much time you’re saving here because the mistake will be found so fast, and once you see it it will be so obvious, that no one will even consider they might have wasted a day on the problem had their partner not spotted it. Nonetheless the effect is very, very real.
On a related note, two minds are better than one. What one programmer doesn’t know the other one likely does. You may not know the details of cuckoo hashing (or even that it exists); but if your partner does, you’ll be able to use it when appropriate. On the other hand, you may be the world expert in the idiosyncrasies of cross-browser JavaScript DOM and save your partner hours of web surfing reading up on how to work around IE6.
As a special bonus, when pairs match programmers with different experiences and knowledge domains, each partner learns from the other. Knowledge effortlessly percolates across the team and the company. This doesn’t speed you up on the immediate project, but it does increase everyone’s skills and improve your velocity on future projects. This is especially important for growing companies.
Try to pair programmers with different skill sets and experience levels rather than similar ones. A pair
is as strong as the strongest pair member, not as weak as the weakest. In fact, it’s probably stronger. The harder and more urgent the problem, the more critical it is to use pairing. If you have some really thorny problem, for instance involving multithreading, don’t pair your top experts in multithreaded optimization. Pair one expert with the lowest intern on the totem pole, so you grow more experts.
If it’s a critical issue and you aren’t sure how or whether you can fix it, pair each expert with a lesser star, and have the pairs both try to solve the problem. Then the pick the best solution, or merge the best features of each. (Caveat: I only recommend this for really important work items that are critical, not for mere grunt coding. For most problems the quality of the solution doesn’t matter so much as just having some solution.)
Mask out distractions
Microsoft and Fog Creek give their programmers private, quiet, distraction-free offices. The rest of us work in cubicles where we have to listen to the web designer two cubicles over yell at Verizon for two days trying to get out of a cell phone contract. Noise is a real problem for many, many programmers. You just can’t think when your brain is in a blender. Your brain does not filter out conversations happening around you. In fact, when no one else is talking directly to you, it deliberately focuses in on these external conversations, whether they’re relevant to you or not, the exact opposite of what it needs to do. It’s like sitting at a table alone in a restaurant, and not listening to the conversation at the next table. You simply can’t do it. White noise would be better.
This is where pair programming really does seem like magic. Your brain has evolved to focus preferentially on a nearby conversation instead of a distant one. When you are focusing on the person next to you, your brain masks out all other conversations at any volume below a shout. The interaction between the pair is so high-intensity that low intensity noise from a cubicle environment is much less problematic for a pair than for a programmer working alone. You can still be distracted from the task at hand by your own name or a few other special cues, but it’s surprising how much noise you can ignore that would completely break your concentration when you’re working alone. That egregious cell phone contract the HTML jockey keeps shouting about? Not your problem any more.
Guaranteed Focus
The eight hour day is a myth. Between meetings, lunch, e-mail, water cooler chatter, personal errands, paperwork, birthday celebrations, collections for going away presents, and more, you’re lucky to get two hours a day of solid coding time. Four hours is great. And even if you have four actual hours to sit in front of the keyboard, how much of that is going to be wasted on e-mail and the Web? Even if the e-mails sent and pages googled are related to the immediate task at hand, it’s likely there’s another e-mail or page just a click away that isn’t work related but is interesting enough to distract you from the real job.
When pairing, programmers actually program. They don’t check e-mail, read blogs, play Scrabulous, and generally goof off. If they have to check a web page to look up the exact behavior of a class (which they’re less likely to do in the first place because one of them may know the answer even if the other doesn’t) they come right back to the IDE after finding the answer. Four hours spent pairing is much closer to an actual four hours spent coding.
One common objection to pair programming is that it’s hard to find four hour blocks in which to pair, especially in larger, more bureaucratic organizations where meetings occupy a large part of the day. But here too pairing can help. Put the pairing time on the shared calendar as another meeting so no one can schedule the pair into meetings when they plan to be coding. Reserve your time for pairing before others take it away from you for less productive activities.
Multiple points of view
Programming has two modes: writing code and reading code. Pair programming has three: writing code, reading code, and explaining code. Explaining what code does makes you look at it differently than simply reading or writing it. When explaining code you are more likely to notice that what you think code does isn’t what it really does.
How often have you discovered bugs in your program when explaining a detailed algorithm to a colleague? Often you see the problem before the person you’re explaining it to does. Not too surprising given that usually the person doing the talking is the one who’s most interested in what they’re saying. There’s nothing like trying to explain something to force you to realize that you don’t really understand what you thought you knew, or that the code doesn’t work quite like you thought.
When pairing, a programmer is always explaining. You’re not just typing while your mind’s really on the World Cup finals or the morning antics of the Zoo Crew on KUPD. The pair members type as they explain what they’re doing and why they’re doing it. Thus, they’re less likely to do something stupid in the first place. If the words coming out of your mouth don’t match the characters emitting from the keyboard, then your partner will likely notice and call you on it.
Reduced training cost and time
Some organizations spend significant (> 5% of annual salary) amounts of money on conferences, onsite classes, online courses, books, and other training experiences for their developers. They may spend several thousand dollars per programmer just to send them to one out-of-town conference, and hope they learn something valuable enough to be worth the airfare, hotel, conference admission, and lost time. Or they bring in a trainer for 1 to 5 days to run a class on a new technology, which can be somewhat more cost effective if you have 5 or more developers and specific subject matter that they need to learn in depth. However you still lose multiple developer-weeks of work to training. Other organizations spend hardly any money on training, and just struggle along with whatever skills the programmers hired on with, as well as whatever they can pick up by reading blogs like this one (though again usually read on company time).
Pair programming doesn’t eliminate the cost of the training, but it can eliminate the lost time and productivity. Instead of purchasing classroom instruction, onsite or online or off, hire a contractor experienced with the technology to pair with your programmers. (The contractor should also be experienced and comfortable with pair programming.) Rather than learning in a classroom (which only works for about 5% of people anyway) help your team learn on the job. Informal lunchtime discussions led by the trainer can cover broader issues and general principles, but the real training takes place as your team builds the system they need training for. Shuffle the trainer between different developers every half day or so, while the ones who’ve already spent time with him or her pair with as yet untrained programmers.
On your balance sheet, it looks like you’ve hired an extra developer rather than a trainer. On your schedule, you’ve replaced training time with development time. Nonetheless, you’ll get a better trained team that can move faster when the contractor leaves.
Although I know a few consultants who specialize in this sort of pair training, I admit they can be a little hard to find. If your team has enough experience with pair programming, you may just want to hire a classic code jockey contractor with experience in the technology you need to learn, rather than an explicit trainer or coach. Pair the contractor up with one of your programmers, and let the knowledge flow naturally. This is a much more effective use of the contractor’s time than just putting them in a room by themselves, and getting an incomprehensible black box out after a few weeks. If the hired guns work directly with your permanent developers, then your team will be ready to take over, maintain, and grow the code after the mercenary leaves. You won’t be trapped in a situation where you have to keep calling the contractor back every two months to spend a few days at $300 an hour fixing the bugs they put into the code in the first place.
Just Do It
Pair programming isn’t magic, but it is effective. Very, very effective. Smart managers and anyone else who cares about code quality and programmer productivity should demand pair programming. In the best code shops, no one codes alone.
July 1st, 2009 at 7:45 am
Ugh. I cannot imagine anything that could make my job as a programmer more unpleasant than being chained next to someone all day long. It’s difficult enough to concentrate while alone in a reasonably quiet office–having someone constantly derailing my train of thought sounds like a recipe for disaster. (Yes, I have done it once, for a few weeks. It was a lot like programming drunk, except less productive.)
July 1st, 2009 at 8:12 am
One of these days I’ll write Part 2: Why Developers Don’t Like Pair Programming; and, maybe even Part 3, How to Make Developers Love Pair Programming. 🙂
July 1st, 2009 at 9:13 am
“The rest of us work in cubicles” — Actually, many of us work in open team rooms with center-facing desks, in eye contact and in earshot of other coding pairs on our team. That works even better since an additional aspect of the “cocktail party effect” is that if one of the background conversations is on point, you magically perceive it, and can chime in. E.g. “the build is broken” or a mention of that part of the code you rewrote last week.
July 1st, 2009 at 1:37 pm
Please do write Part 3. Because though I agree with some points of what you say, if anyone ever forced me to pair program I’d be out the door the next day.
July 1st, 2009 at 1:45 pm
Yeah, I have to admit that all the above sounds great… but what happens when you’re paired with yr manager or HIS manager and watching them code is the scariest thing you’ve ever seen?
They’re trying to show off most of the time by coding as fast as humanly possible.
Turning the nontrivial into the trivial.
Short-changing the requirements.
They’re actually a pretty terrible coder because their skills are really in another domain. and because they’re essentially doing something somewhere in between performance art and a gratuitous slam dunk on a 7 year old. They’ve essentially stopped thinking about all the patterns they usually badger us about.
You can’t really critique them because they believe (and essentially are) the senior pair member. (and truthfully, in their element, they are quite skilled.)
You realize that half the code being written will have to be changed later and/or that it’s going to inadvertently make it to production via various snafus and cause customers trouble.
You also know that you’ll have to live with this code, not them. They’ve got twelve meetings, six conference calls, and an executive retreat to attend. It’ll be your phone that rings on the weekend.
Ugh. Special case. I’m sure. Still. Where some of us live.
July 1st, 2009 at 1:51 pm
Okay, i admit it. I HATED pair programming. At first. Just ask Alex – he had the unfortunate “honor” of introducing it to me. I may, MAY, have been a bit of a bastard about it. 😉
But then……. I did it. At first, I still hated it. But the reason I hated it had little to do with why I *thought* I would hate it. Before I had even tried pairing, I already hated it because I thought my personal space (a funny term given that you don’t really have personal space in an office – right?) was going to be infringed upon, that my time would be taken away from such important things like reading popsugar, etc. etc.
That’s NOT the reason I *really* hated it, though. The reason I hated it is because – are you ready for this? – I might be wrong. Yes, there is a slim chance I could be wrong – dead wrong, stupid wrong, or better yet, absolutely completely “WTF were you thinking of implementing it this way you dumbass!” wrong – and my pair would find it and point it out to me. In other words, I was afraid of being naked.
The fear was being critiqued. But then I did it. And sure enough, I may – MAY – have done a few things in a less efficient manner. But something amazing happened – I learned. I learned a lot faster with someone at my side than I could ever have learned alone or during/after a formal code review. My pair helped me organize my thoughts – and funny enough, I helped my pair as well. My pair helped me get up to speed QUICKLY on the new system being developed. Faster than I could ever have done it alone.
I learned new development techniques that have stuck with me, even today. Things I’m not sure I could have learned on my own.
Getting developers to pair – I think it’s important to think about the human aspects of software development when introducing pairing. Sounds obvious – and Agile development does try to focus on the human element. Sometimes we forget about the human element when we introduce some of the core engineering practices.
I dunno if I can make a blanket statement and say that most developers who don’t like pairing (before they’ve done it) are afraid of “being naked” (although, so far in my experience during coaching, this is usually the primary reason), but you have to try and convince the person being coached that you’re not there to critique their code. I got around others’ fear by explaining that I want to pair because *I* want to learn from *them*. In other words, go humbly forth to the dissenter.
That humble attitude is, BTW, one of the things I learned through pairing, in addition to being a better coder.
🙂
July 1st, 2009 at 1:54 pm
Great list!
I would add:
1. It creates “live” coding conventions that evolve naturally.
2. Once people “get it” everyone is less stressed, defensive and stubborn and more enthusiastic, courageous and engaged
3. Sustainable pace and taking vacations/sick days happen easily
I could write a book for #2 and have no suggestions for #3 other than force them to do it for a while (and do it well), then revert back. Especially when people dislike it, its hard for them to see past frustration. Reverting back allows them to re-experience the dysfunctional nature of sole programming.
Pairing is difficult to start with an I/me/mine oriented team. Pairing is successful when people see success as a team endeavor instead of the result of individual efforts. It
July 1st, 2009 at 3:14 pm
[…] Pair programming drives up productivity and quality of code. […]
July 1st, 2009 at 3:15 pm
[…] quality. Agile’s promotion of daily meetings, frequent customer interaction, no overtime, pair-programming, moving people around, continuous integration and test-driven development all effectively address […]
July 1st, 2009 at 3:52 pm
Word!
You write the truth. I totally love pairing. The quality of the code is amazing and further more the speed at which the pair reaches that quality is even more amazing. Another thing I love about pairing is that you do not get interrupted. When I sit by myself it’s like people think I have nothing better to do than ask questions. When I pair with someone they leave us alone!!
July 1st, 2009 at 4:55 pm
Pair Programming may lead to continuous code review, but it doesn’t and shouldn’t replace formal code reviews or walkthroughs by peers who have had no hand in creating the code being examined. Pair Programming is as susceptible to “groupthink” as any other committee-based effort.
July 1st, 2009 at 6:07 pm
I agree 100% with the author. I have been practicing pair programming for almost 2 years and it made me a better developer in many ways. Pair programming enabled me to learn from my peers and inturn share my knowledge with them to make them better. By pair programming we were able to enforce standards in the team, consistant way of writing code and doing things resulting in fewer bugs and producing quality code.
July 1st, 2009 at 7:31 pm
I was doing pair programming back in the 70s, for the very good reason that my friend and I had only one computer between us.
I like to say that the reason programmers should do pair programming is the same reason the Enterprise has two people in front of the big viewscreen: one’s a pilot (local, immediate concerns) and the other’s a navigator (keeping track of where we’re coming from and where we’re going.)
July 2nd, 2009 at 11:06 am
“Pair Programming may lead to continuous code review, but it doesn’t and shouldn’t replace formal code reviews or walkthroughs by peers who have had no hand in creating the code being examined.”
Boehm and Phongpaibul reached a different conclusion in “A Replicate Empirical Comparison between Pair Development and Software Development with Inspection” (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4343754) The quality of code written in pairs vs. code written individually and inspected was identical as measured by the number of passed test cases. Also, the whole idea behind programming in pairs is to avoid the groupthink mentality. Peer pressure is significantly reduced when working 1 on 1 with someone.
July 2nd, 2009 at 12:38 pm
I dont have any problem if some one see my code, send me questions or things to change, or say that i am a bad programmer. Really is fine with me
But if someone sit next to me and question everything i do or interrupt my thiniking, i will to punch him/her in the face
July 2nd, 2009 at 7:01 pm
ERH, “slight of hand” should be “sleight of hand”.
July 2nd, 2009 at 10:53 pm
One secret or fact. Typically XP Shops look for Rock Star programmers. So if you’re not a rock star programmer (a LOT of us are not and are average developers which is just fine), then XP may not be for you…too much pressure.
July 3rd, 2009 at 10:17 am
Sorry, Anonymous, but XP shops do not look for rock star programmers. On the contrary, many shops are turning to the craftmanship approach and higher more less experienced programmers and mentor them.
It’s also nice that so many hate pairing and will never do it. With so many programmers and so few jobs, it’s nice to have a quick way of weaning out the weak.
July 3rd, 2009 at 5:37 pm
We pair 100% of the time at Hashrocket. There are definitely more pro’s then con’s to it. Here’s my take on each of the comments so far, since pairing is something I value A LOT.
@mike: A “few weeks of pairing” isn’t going to change your mind. It’s going to take MONTHS to get used to. Perhaps maybe give it another chance? Also, pick someone to pair with that is just as passionate.
@alex: Open-offices are awesome for turning around and claiming code that someone else may be working on. We’ve seperated ourselves into 3 big conference room-type rooms though since 16-20ppl pairing 100% of the time gets kinda LOUD.
@c.doley: Walking out the door won’t help you as a developer if being given the opportunity that very few companies would even consider doing. Don’t be “that developer”.
@wendy: I agree. A big thing we do in our shop is “Pair Promiscuity”. We have a pair-stair and we rotate pairs, daily. Once everyone is ramped up on all the projects, we can interchange on a daily basis to protect against someone getting sick or vacation or worse, hit by a truck.
@anonymous: They also look for non-rockstar developers that are ambitious and want to learn. So what better way to bring them up to speed? Pair them with a Rockstar that they would not normally get the chance to pair with. 😉
@curtis: Couldn’t have said it better. Interviews in a conference room with a resume in hand is the most retarded way to hire someone. Pair them with all the levels of people in your office that they would have to work with anyway. We bring people in for 1 week of pairing. The surprising thing these days? The person being interviewed needs to be a better cultural fit then a rockstar developer. Rockstar developer status can be obtained through learning. Having to work with a arrogant asshole can’t. Well it can, but firing people kinda sucks.
July 4th, 2009 at 10:55 am
I think I read it all, and I don’t see that you say that you: currently pair program in your day job, or ever pair programmed in a previous day job. Lots of proscription, but no “I did this and it really does work”.
July 4th, 2009 at 7:33 pm
[…] The Cafes » Why Pair Programming Works […]
July 4th, 2009 at 8:00 pm
[…] Good article explaining Why Pair Programming Works. […]
July 5th, 2009 at 10:18 pm
@Corey: I’m not sure I understand what you’re saying. I really do want to know how to make developers love pair programming.
@Michael: I like your story, but I’m not sure it applies to me. I love arguing, and I love being proved wrong. I dislike having to justify every little decision and coming in behind schedule because of it. I find that my code and productivity is much worse when working too closely with others on the same problem. There’s such thing as too much feedback.
I speak from experience (in jobs, in education, in life) that when you pair a smart person with a dumb person the dumb person does not get much better and the smart person does a LOT worse. Of course, it’s entirely possible (if unlikely) that a pair consists of two people of roughly equivalent skill. In this case, I suspect they do better than they otherwise would. But enough better to justify double the cost? Not in any case that I’ve ever seen.
Now I should also say that I’m a huge believer in mentoring. I once put my best guy next to someone who was on the verge of being fired. After about 3 months she was the second best member of the team. But I have no illusions that I paid for this by having my best guy operating at much less than 100% during that time. It was a worthwhile trade, but not something I’d be sticking with longer term if possible.
But back to the original point. Assume I’m a programmer and not a manager. I really do want to know why I would be interested in something like this. I’m quite skilled and can walk out the door and into another job in a day. So tell me something besides “fewer interruptions” (which is huge, but can be bought much cheaper).
July 7th, 2009 at 11:02 am
Successful pair programming is predicated on good relationships. There’s nothing I enjoy more than pair programming with someone I am comfortable with, I respect and I trust. Reading through responses, most of the strong reactions to pair programming are heavily tied to relationships:
Mike – “being chained next to someone all day long”
mipsy – “You can’t really critique them.” (Trying to work on level footing with a boss – Awkward!)
Chocolim – “But if someone sit next to me and question everything i do or interrupt my thiniking, i will to punch him/her in the face” (Strong emotion…)
Pair programming is nothing more than working together to solve a problem.
When you think of it like this, it’s obvious that it will fail miserably in a couple circumstances.
– When two people can’t work together
– When there’s no real problem to solve (simple work)
It’s obvious that it will have some advantages:
– Working together can build trust and respect
– Two heads are better than one on difficult problems.
August 14th, 2009 at 9:52 am
The Cafes » Why Pair Programming Works…
Pair programming is like magic in more ways than one. It dramatically improves programmer productivity and reduces bug count, and yet it does so through a technique that’s completely counter-intuitive. You can’t help but think that there’s some t…
September 15th, 2009 at 11:53 am
@erh: Good stuff! If you ever do write part 2, you may find my list of 21 ways to hate pair programming useful.
October 12th, 2009 at 6:44 am
[…] you want to read more http://cafe.elharo.com/programming/why-pair-programming-works/ […]
February 19th, 2010 at 10:02 am
I’ve tried pair programming several times and it’s always been useful and even fun. I always learn from the person I’m paired with. It also exposes differences in belief about standards (big and little S), in the long term that makes the team more coherent.
April 19th, 2010 at 10:53 am
I have been doing pair-programming for about 1.5 years and I agree with every point the author makes, except one.
In my experience, it is important to pair programmers of differing skill levels, but pairing an expert with the lowest intern to work on a very difficult problem can be a disaster. I’ve been the expert in a situation like that and it did not work. The intern and I spent all of our time just figuring out how to talk to each other because there was such a disparity in our experience. It would have been much better to have worked with a mid-level developer who, although they may have not been familiar with the particular problem domain, had enough experience to that they could be brought up to speed fairly quickly. I guess it depends on the definition of “intern” within a particular team.
One additional point that I would like to make is that the increased focus and productivity of pairing can be physically exhausting at first. When my partner and I started pairing, it took several weeks before we could go home at the end of the day without feeling like we had been “put through the wringer”.
June 26th, 2010 at 5:48 am
[…] quality. Agile’s promotion of daily meetings, frequent customer interaction, no overtime, pair-programming, moving people around, continuous integration and test-driven development all effectively address […]
July 31st, 2010 at 9:11 am
[…] Pair programming drives up productivity and quality of code. […]
January 7th, 2013 at 5:15 am
[…] love pair programming, some hate it. Someone is even scared of it. Let me quote Michael Dowling in cafe.elharo.com comment section: That’s NOT the reason I *really* hated it, though. The reason I hated it is […]
May 13th, 2016 at 11:13 am
[…] of the things he’s a great advocate of is “pair programming“, and he was explaining how he’s been using Cleanfeed instead of Skype, to send and […]
July 3rd, 2017 at 8:36 am
Utter nonsense and the dumbest idea to ever evolve in I.T. Created by and for some lame brain consultant that has NEVER written a SINGLE LINE OF CODE!
July 27th, 2017 at 9:59 am
BS, pair programming is the DUMBEST idea to come down the pike. Why should I teach some junior programmer how to code? That’s NOT MY JOB! I didn’t sign on to teach, I signed on to write code – period.
Stop trying to save money by making me do something for FREE!
July 27th, 2017 at 10:01 am
Anyone else notice all the comments in favor of “pair programming” is a stupid consultant. Bet you a dollar he couldn’t find his own *** with both hands and an Admiral Byrd Expedition.