Say "pair programming" to a programmer and he'll probably frown or turn his back on you. But add some rules the programmers must follow--rules that help maintain each person's sanity--and he just might come to find this practice rewarding and beneficial. This article, originally published on Jeff Langr's website, explains the rules and how certain teams have reacted to this structured version of pair programming.
Pair programming is one of the most contentious practices of extreme programming (XP). The basic concept of pair programming, or "pairing," is two developers actively working together to build code. In XP, the rule is that you must produce all production code by virtue of pairing. The chief benefit touted by pairing proponents is improved code quality. Two heads are better than one. Note that pairing is a practice that you can use exclusively of XP.
However, a large number of developers despise the notion of having to sit next to someone for the better part of their work day. Reasons for resistance can include:
- the belief that pairing is a waste of time and ineffective
- the belief that pairing should only be used occasionally
- fear of exposing personal weaknesses
- personality issues, including introversion
Pairing is not for everybody. But too many people resist pairing based on a knee-jerk reaction to what they understand it to be. Usually, the practice and its benefits are not fully understood.
There are only a few simple rules to follow if you choose to do pair programming. First and foremost is that all production code must be developed by a pair. Conversely, thi smeans that are plenty of other activities that you can undetake in the absence of a pair:
- work on any non-production code: the acceptance test framework, other tools, build scripts, etc. In most shops, these are in dire need of attention.
- work on documentation
- work on spikes for future stories
- learn how to use a new third-party product; learn a new coding technique; and so on
- identify problem spots in the production code that need refactoring
- refactor tests
- improve the existing test coverage if necessary
Any of the above could be done better if a pair were available, but they are usually lower risk activities. If time is absolutely a factor, the non-pairing developer can work on production code, but with the insistence that such code is peer-reviewed after the fact.
Having a non-pairing developer work on production code should be the exception, not the rule. As such, it should be justified and treated as a high risk activity.
The second pairing rule: it's not one person doing all the work and another watching. During a good pairing session, the keyboard should be moving back and forth between the two participants several times an hour. The person without the keyboard should be thinking about the bigger picture and should be providing strategic direction. They should also be helping to ensure maximal code quality and minimal defects.
Third, don't pair more than 75% of your work day. A good, productive run of 6 hours of software development is mentally exhausting. Make sure you take breaks! Get up and walk around for a few minutes at least once an hour.
Finally, you need to switch pairs frequently. Working with any one person for any extended duration will not only drive you nuts, but you will begin to lose the benefit of getting fresh outlook on problems. Minimally, switch pairs at least once a day. In fact, I promote switching pairs once in the morning and once in the afternoon. In addition to getting new insight on solving a problem, there is another, less obvious, benefit to frequent pair switching.
When you sit down to work with a new pair, you must switch mental contexts from the task you were working on to a whole new problem. Context-switching is difficult. Work for only 55 minutes then switch tasks? Seems outrageous. One might think, "It'll take almost that amount of time