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.
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vhUNdO2IUBCv7fA_KLjvmdsBTHlz4JuEZo_2bFC3H1bITWUz96oFrHXCHmmZqM5y_B826leb9Q1cSBkfuqrpNIqI0ntxB-oLcmgutzmvYNKZdGfybnWy--ZUYZ9wMHPmIQrwsSLCsmh5APC4eKfcU=s0-d)
