Improving Code Quality with Pair Programming

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.


About Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Tagged , , , , , . Bookmark the permalink.

2 Responses to Improving Code Quality with Pair Programming

  1. Even before Brooks and Constantine, programming-style pioneer P. J. Plauger was there, not only defining and describing pair programming, but using it and researching it. Now that it has become popular, many are claiming to have invented it or to have been “doing it all along,” but Plauger deserves the real credit for it’s origination as a deliberate, structured technique for programming. While teaching in Australia, he did early research testing its effectiveness and in the 1970s was using it as standard practice at Whitesmiths Limited, the erstwhile tool developer. It was P.J. who introduced me to the technique.
    –Larry Constantine (Lior Samson)

    • BenLinders says:

      Larry, thanks for clarifying this!

      So credits to P.J. Plauger for for all the ground work that he did on pair programming; a technique which the software community is using to develop high quality products.

Leave a Reply

Your email address will not be published. Required fields are marked *

  • Ben Linders – Independent Consultant Agile, Lean, Quality, and Continuous Improvement

    Ben Linders
    Ik help organisaties om effectiever software te ontwikkelen. Neem contact op voor mijn diensten.

    I help organizations to effectively develop software. Contact me to hear about my services.
  • Games and Books

    • Agile Self-assessment Game 9.99 (Excluding VAT)
    • What Drives Quality (eBook) 8.99 (Excluding VAT)
    • Getting Value out of Agile Retrospectives (eBook) 8.99 (Excluding VAT)
    • Business Agility Expansion Pack for Agile Self-assessment game 1.99 (Excluding VAT)
    • Waardevolle Agile Retrospectives (Paperback) 14.05 (Excluding VAT)
    • Agile Self-assessment Game - Polish edition 9.99 (Excluding VAT)