Improve Developer Productivity with Pair Programming

Two programmers working together can produce better-quality code

Pair programming, as described in the book Pair Programming Illuminated, by Laurie Williams, a professor in the Department of Computer Science at North Carolina State University, and Robert Kessler, a professor in the School of Computing at the University of Utah, is a simple concept that can potentially improve the quality of code and provide other benefits to software development teams. I've used pair programming off and on for many years and found it to be a helpful software development practice. In this article, I elaborate on some of my experiences with pair programming to give you a sense of its benefits as well as some potential problems to watch out for when working in pairs.

What Is Pair Programming?

Pair programming is a style of programming that is associated with Agile development -- although it can be used in non-Agile projects -- in which two programmers work side by side at one computer continually collaborating on the same design, algorithm, code, or test. One of the pair, the driver, is typing at the computer or writing down a design. The other person, the navigator, has several duties, including observing the work of the driver on the lookout for both tactical and strategic errors. Tactical errors are those such as syntax errors, typos, and calling the wrong method. Strategic errors occur when the driver is headed down the wrong path -- that is, what's being implemented simply won't accomplish what needs to get done.

The crux of pair programming is that it fosters a continuous, real-time code-review process. The review is one of the most powerful tools we have in software development. A programmer who takes a look at another programmer's work can often find a lot of issues quickly.

Pair Programming in Practice

Conceptually, pair programming is rather simple in that it's just two programmers working together at one computer and on the same task. In practice, pair programming is a little more involved. However, if pair programming is done by following some guidelines, it can be an effective and more efficient method than traditional programming. When done correctly, pair programing can produce more and better-quality code than individual programming. It can enhance morale, foster trust among team members, provide knowledge transfer, and enhance learning.

I first started using essentially what is now known as pair programming in the early 1980s. In developing software for mainframe applications at the National Security Agency, our team had only a limited number of IBM 3270 dumb terminals to use. We also had new programmers to train. So, to make the best of our situation and limited resources, we paired up on development tasks. Within a few weeks, we found that we caught more errors sooner and were able to more quickly get new developers up to speed. I used pair programming again years later in a crash project to get a large body of software moved off a mini computer for a Y2K project. As consultant to the effort, our group had a number of developers new to web development and needed a way to get the development done on time and accomplish a lot of knowledge transfer quickly. Teaming up in pairs proved very beneficial on this project and allowed us to attain both of those objectives.

Potential Problems

There are several potential problems to watch for that indicate pair programming isn't working. One is unequal access to the keyboard and mouse, so that the two individuals don't have enough space to sit side by side to view the computer screen(s). Another potential problem is keyboard domination -- that is, one partner dismisses (verbally or otherwise) the other's work or input into the project. Another potential problem is that unhealthy relationships can develop. Pairs need to be changed frequently so that people don't tire of each other.

A final problem to watch for is the "endless debate" problem, where programming partners over-analyze how to derive a solution. Any debate longer than about 10 minutes should be resolved by each member of the pair actually coding what they're trying to explain. Arguing in code is better than arguing about code. The goal is to get the project done, so whatever method works and accomplishes the goal more quickly and correctly is the best solution.

A Valuable Tool

I've found that pair programming can help software development team members improve their coding skills and knowledge more quickly and produce better-quality code in a variety of settings such as mainframe development, database development, and web development. I suggest you look into pair programming. Please share your pair programming experiences with the Dev Pro team, or feel free to email me.

Alan Noel is a principal consultant with Microsoft Consulting Services in the Washington, DC, area. He has been working with SQL Server for 13 years.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.