Frequently asked questions about pair programming

Pair programming is an agile development technique where two programmers work together at the same workstation, that is, developing the same code.
One of the people, called the driver, is responsible for writing the code, and the other person, called the observer or navigator, reviews the lines of code as they're written. Think of the famous Rallies, where one person is the driver responsible for driving the car, while the other is the navigator, responsible for reading the map and deciding the strategy to follow.

But why put two people on the same code if I can have them working separately and producing twice as much code?

Pair programming generally increases the number of hours needed to deliver code when compared to two developers working alone at their own workstations. Some experiments say this increase in delivery time can range from 15% up to 100%; however, the code produced has about 15% fewer defects, and often the cost of fixing those defects in production is higher than the cost of having two people pair programming.

In my experience as a development consultant, projects were delivered with more maintainable, higher quality code compared to the years I worked alone. More maintainable because, by combining the experience of two developers plus the eye of the person acting as navigator, we were able to do more frequent refactors and have cleaner code. Higher quality because we could combine other techniques, like ping-pong (described below), with test-driven development (better known as TDD).

Should I pair program 100% of the time?

The answer is: It depends.

Pairing 100% of the time depends a lot on the project context and the task at hand. The pair programming process often gets tiring after a few hours (that's where some techniques described below come in), and some simpler tasks that the team already has context on can maybe be done solo.

How often should I switch pairs within my team?

The answer, again, is: It depends.

It depends because different teams have different contexts. On one team I worked on, we wrote small stories and split some of them when we thought they were too big, which meant we switched pairs after finishing a story. At some points in the project we rotated pairs more often (like every 3 days) to share business and code context across the team.

A tool you can use to keep track of pair rotations is the pairing matrix, where you write down who paired with whom and how many times those people have paired. This way we reduce people's pairing preferences within the team and get everyone pairing with everyone.

What techniques should I use to switch between the driver and navigator roles?

The pomodoro technique consists of setting a timer for an interval of time. For example, you set 25 minutes in which one person works as the driver, and after those 25 minutes you take a 5 minute break to rest. When you come back, the person who was the driver becomes the navigator, and so on for 4 rounds of 25 minutes, after which you take a longer break of, say, 15 minutes.

We can use TDD together with a technique called ping-pong, where one person starts as the driver, writing a test and making it fail. Then the person who was the navigator becomes the driver, makes the test pass, and writes another failing test, switching the pair again, and so on.

My view on pair programming

From my point of view, pair programming brings far more benefits than drawbacks, like sharing context across the team and sharing experience between more experienced and less experienced developers. Plus, if a developer gets sick, leaves the project, or even decides to leave the company, other people will have context on what was being developed. It's important, though, to use some of the techniques mentioned above so pair programming doesn't become a tiring task.

And you, do you use pair programming on your team? Do you have a different point of view? Comment below :)