Results through Pair Programming

November 12, 2010

When you hear the term Pair Programming, what thoughts come to mind?

Let’s talk about the elephant in the room: As a manager, does pair programming conjure up thoughts of paying two people to do the job of one?

Since we’ve adopted Agile development, pair programming is naturally something that we’ve tried. I recently decided to take a quick scan of the Internet to find some research papers and experiences to compare against our own experience. I was interested in how others were approaching pair programming, the benefits obtained, and any valuable insights that could be gleaned. I’ll focus this post on what pair programming is and what to expect in general.

The classic definition of pair programming is that it involves two programmers collaborating at one computer to develop software, using two distinct roles:

The Driver: The programmer who is actively writing code by typing it into the computer. The driver is tactically focused on the current code.

The Navigator: The programmer who observes the work of the driver, making notes on how to improve the code, considering what to work on next, or how the current code fits into the overall design.

The driver is free to work exclusively on creating rigorous code without worrying about the big picture, and the navigator is free to consider strategic issues without worrying about the immediate code that is being produced. A conversation precedes any driving and helps synchronize the two programmers on the direction that the code as a whole is taking.

People do pair program using this classic definition. Shane Warden and James Shore wrote about this in their book, The Art of Agile Development. This technique certainly works, but I feel that there are a few key ingredients required:
  1. Discipline. Each person must understand their role and hold themselves to fulfilling that role without “jumping the fence.” The navigator in particular must keep his or her concentration on what to do next, resisting the urge to jump in on typos or other trivia while observing the driver.
  2. Similar Skill Levels. Since different aspects of the same work is being shared (and programmers will likely trade roles during pair programming), both programmers must possess the skills to perform the work independently.
  3. Trust: A programming pair must have confidence in each other and the skills that each brings to the table, otherwise the driver will be devoting cycles about what to do next in the back of his or her mind while coding, or the navigator will be spending too much attention on the tactical aspects of what is being coded now. 
As I noted, this defined driver/navigator collaboration is the classic definition of pair programming, but there is another reality, one closer to how we pair program: conversation and collaboration as a pair, talking the whole time and dealing with tactical coding and the strategic issues together.

This approach was confirmed in an article, How Pair Programming Really Works by Stuart Wray. In the article Stuart says, “My own experience as a developer using pair programming is that it isn’t just a technique where one person programs and the other person watches. Both programmers work closely together, chatting the whole time, jotting down reminders of things to do, and pointing out pieces of code on the screen. Programmers take turns at the keyboard, usually swapping over with a phrase like, ‘No, let me show you what I mean.’”

Stuart cites supporting research by Jan Chong and Tom Hurlbutt, who spent several months on a study of professional developers using pair program¬ming in their daily work. Stuart notes, “They found that pro¬grammers tended to work together on the same facet of a problem almost the whole time and swap between tactical and architectural levels as a pair.”

In the end, does pair programming take twice the effort? Not if programmers are working on difficult, complex tasks where it makes sense to be collaborating in the first place. Pair programming has its place, and for the simple tasks it is more efficient to have programmers work independently.

When you start pair programming, there is typically a small period of time (this varies by the individuals involved) required to get used to pair programming, and productivity will dip. In the long run, studies cited in The Costs and Benefits of Pair Programming show that you should expect a 15% increase in development-time costs, not 100%. Other studies show that work is completed faster than it would be through individual programming. In the article, Strengthening the Case for Pair Programming, it was noted that, “Because the pairs worked in tandem, they were able to complete their assignments 40-50% more quickly.”

Two brains being applied to one difficult, complex problem definitely help to improve the quality and speed of the work being performed, but there is another factor that comes into play, and that is ”pair-pressure.” Comments from the programmers studied in the articles referenced above confirm that programmers work harder and smarter because they do not want to let their partner down.

It is important to note that the mental effort involved with pair programming will be more taxing. Your mind is working at a higher concentration level, and this means that you will tire by the end of a day – sustainable development is a must! I’d like to say that pair programming is a case of working smarter, not harder, but the reality is that you do work harder. But it should be focused, time-boxed work.

To be productive on a sustainable basis, there must be re-charge time built into the cycle, and that means strictly limiting, if not curtailing, overtime. Too many mistakes get made when people are tired, and as long as pair programming is creating higher-quality code in less aggregate development time as a whole, then it is something that we should all embrace.