The quality of software is often still insufficient. Testing, though essential to prevent defects slipping from the project to customers, can be expensive and time is often limited. Pair programming is a proven technique that prevents defects from entering the code.
Pair Programming is done by two developers who share one keyboard and screen. One developer is typing code, while the others reads the code, signals potential problems and suggests improvements. Developers can change roles during a session, coaching each other in developing quality code.
The biggest benefit of pair programming is improved code quality. It also improves communication between team members, and support learning and continuous improvement of development teams. There is evidence that pair programming improves the quality of products and that it improve product quality, improve team spirit, aid in knowledge management, and reduce product risk. Given the higher costs of defects that are found late in a project or after release, pair programming saves money. Finally it reduces risks that disturb project and impact the timely release of products.
Pair programming has become more popular since its recognition as an agile practice. The CMMI V1.3 mentions pair programming as a technique that can be used for the verification of code (yes, the CMMI V1.3 support Agile, as I described earlier). But actually, developing software in pairs is much older, and has already been described by Fred Brooks in the Mythical Man Month and by Larry Constantine in Constantine on Peopleware, long before agile incorporated it as one of the practices.
Pair programming is not only for code. I’ve been doing pair programming on Unix command lines, where we formulated command strings to parse files using pipes and unix tools like awk, sed and grep. Those command lines became quite complex, so it really helped when a colleague looks over my shoulder while typing. In another situation I had to do some data and reference corrections directly in a Microsoft Access database. Since the risk of messing it up was quite big, we sat together and checked each field that we changed before hitting enter. Actually my first pair programming was back at school, when assembly programs had to be typed into a processor kit using hexadecimal code. I learned pair programming the hard way, after entering a program for half an hour and finding out that I missed one line. The processor kit had no insert mode so I had to retype the whole program, with the risk of making a similar mistake; so I asked one of my classmates to sit aside and watch me typing, and stop me when I was making a mistake.
What about code review? You could consider reviews to be “time and place dispersed pair programming”, since the code is also being looked upon by somebody different as the developer, but this person is not sitting next to the developer when (s)he is typing. The quality benefits of code reviews have been published over the years, see for instance publications by Capers Jones, Karl Wiegers, and the results that I accomplished with the Project Defect Model. So if you don’t have the opportunity to pair, you can still improve code quality by using code reviews.
So if your are ever in a situation where you have to write code that is more complex or critical, then team up with your colleagues and use pair programming to prevent defects from entering your code.