The quality of software is often still insufficient. Testing, though essential to prevent defects slipping to customers, can be expensive and take much time. 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 other one reads the code, signals potential problems and suggests improvements. Developers can change roles during a session, coaching each other in developing quality code.
Benefits of Pair Programming
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.
My experience with Pair Programming
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 looked 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 that I collected in Business Benefits of Reviews 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 you 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.
Pair programmings is one of the techniques explored in the Coding chapter from the book What Drives Quality. This book explores how quality plays a role in all of the software development phases, it takes a deep dive into quality by listing the relevant factors of development activities that drive the quality of products. It provides a lean approach to quality, which analyses the full development chain from customer request to delivering products.