Pair Programming


March 10, 2017

This post is mostly about how we do pair programming and things that we've learnt in the last few years about effectively doing it. We've also included some quirks that you will notice when you start practicing pair programming. So we've tried to focus less on the what and more on the how.

We follow pair programming for most our work. It helps us maintain a high quality of code and an extremely low defect rate. It can also be a great way for a new programmer to be inducted into the team as it accelerates learning.

Pair programming involves two programmers working on the same piece of code at the same work station. One programmer (called the driver) writes the code, while the other(called the navigator) reviews the code being written. And these roles have to switch frequently. So, the two practical aspects of pair programming are code review and frequent role switching.

Code review

Pair programming, like many other practices of extreme programming, is a software engineering practice taken to the extreme - in this case code review. The driver writes the code while the navigator sleeps. The two programmers switch roles frequently so that both of them get enough sleep.

Just kidding! The driver writes the code and takes care of the low level implementation details while the navigator reviews the driver’s work from a higher level of abstraction.

If you are only beginning to pair program, it might be beneficial to have a checklist written down on a piece of card and stuck somewhere near your monitor. This is what we call a navigator checklist. This checklist contains questions that a navigator needs to keep asking himself (and sometimes the driver) during development. Here’s a sample checklist -

It is highly recommended that you modify this checklist as you learn more about your pair and from action items that you get from cause effect analysis of bugs. Also based on the experience levels of the programmers, some of these will make sense while others won’t.

Frequent role switching

There are two common styles followed to switch roles during pair programming. First one is to use the Pomodoro technique. This basically breaks down the work into 30 minute long intervals (25 minutes of coding + 5 minutes of short break). After each interval the pair switches roles. This can work great when role switching is followed religiously. But more often than not, it might be hard to unglue programmers from their keyboards at the end of a Pomodoro and when this happens frequently, the navigator might lose focus/interest.

The other style is called the Ping-Pong pairing developed by Corey Haines. In its simplest form, one programmer writes the test and the other takes care of getting the test to pass. This is a very powerful style as this drastically improves the involvement of the programmers and also clears doubts as to when to switch roles.

Other things to be considered

Where do you go from here?

It is a little counter intuitive but we have observed that in most cases and in the long run, pair programming helps you be more productive than working alone. If you have never done pair programming before, it can be hard to buy the idea of two people working together on a single task when they could have been working on two different things in parallel. So how do you give this a try? Here's something that we tried with one of our teams.

  1. When things are not very hectic, add some slack to a sprint and get two programmers to pair on a story

  2. Ensure that the pair follows the practice with discipline even if it feels ridiculous at times. Eg., if you are following the Pomodoro, it might feel ridiculous to stop exactly at the end of 25 minutes when the driver is just a couple of minutes to logically conclude the task at hand. But it is necessary to follow the practice to the T, at least initially.

  3. It might be necessary to enforce a rule saying no discussion should go beyond 10 minutes as there will be a tendency to spend a lot of time on discussing to make decisions. Of course there will be exceptions.

  4. Somewhere in the middle of the sprint, replace one person in the pair.

  5. At the end of the sprint, get feedback from all three programmers involved in the experiment.

You should definitely see an improvement in their productivity and code quality. As with any new technique, it makes sense to follow the ShuHaRi.