Two Sets of Eyes, Part 3: Why Pair Programming works (despite the objections)

Last time, we talked about the different flavors of two sets of eyes. They exist on a continuum that we see as:

  • maximizing communication efficiency;
  • maximizing code design quality; and
  • minimizing rework.

The last two options on that continuum are flavors of pair programming (or “pairing” for short):

  • Pair program with another person only at certain points while writing the code (opportunistic pairing).
  • Pair program “full-time” with another person while writing the code.

We define pairing as two developers/designers working on the same code on the same machine at the same time. Yes, the same machine, at the same time.

You’ve probably heard of it, or you may have done it. Unless you’ve been asleep for at least the past decade, though, you’re probably aware that pairing is hotly debated among people involved with software development. You’ll find vocal detractors and defenders without looking too hard. Which opinion is right?

We frequently side with the defenders, with one caveat: Pairing only makes sense when it makes sense. We don’t do it all the time. We’ve had great results with it when it made sense, and we’ll gladly defend it as a practice in those cases. As the African proverb says, “If you want to go fast, go alone. If you want to go far, go together.”

The objections to pairing aren’t new. In fact, most are reasonable, given the perspective of most software development project managers. One blog post isn’t enough to cover every nuance, but we can address some of the most common objections and give our perspective on how accurate they are.

“It’s twice as expensive.”

Despite what vocal devotees of pairing claim, this is reasonable point. It makes sense for a manager to critique the additional cost of having more than one person work on the same code at the same time. The problem with the objection is that it ignores (or seriously discounts) the economic gain of pairing, and it exaggerates the costs.

The economic gain of pairing comes from four primary sources:

  1. Two heads often are better than one, which improves your code design, which often makes code easier to change later with fewer side effects. That reduces the total cost of ownership of your software.
  2. Pairing is like a constant code review, but with all of the necessary context to make that review excellent. This leads to fewer bugs, which often cost a boatload to fix later.
  3. Sometimes (not always), having more knowledge spread across the team can make the entire team faster, which reduces the time to value ratio for the software.
  4. Nearly all the time, having more knowledge spread across the team lowers risk by reducing the team’s “truck number” (the number of people who have to be hit by a truck before the project fails).

The challenge is quantifying that economic gain, because true comparisons aren’t feasible. How many companies do you know who are willing to do the same project twice, once with pairing and once without, and then compare total costs? We don’t know any.

Even if that comparison were possible, it still wouldn’t be entirely accurate, because you’d need the same team to do the same project twice so you could measure the independent effects of pairing. But the team would be smarter after doing it the first time, and the approach they used for the second try would benefit from that. It’s not comparing apples to apples.

Our experience tells us two things:

  1. the benefits are real when we compare similar projects done with pairing and without it, or with more or less pairing; and
  2. the costs of pairing can be, and often are, offset to some degree by the economic gains (i.e., a pairing project shouldn’t cost two times the non-pairing variety).

In fact, some empirical research shows pairing adds about 15% overhead cost (not 100%), but reduces defects by about 15%, which can lower overall cost of a system. You need to decide which costs more. It could be a wash, which would suggest that the other upsides of pairing could add up to a non-trivial economic benefit for your organization. (see

“It’ll slow down the team.”

It might, at least in the short term. Pairing takes time to get used to. Knowing how to be a good “driver” and a good “navigator” (the two pairing roles) takes some experience. With practice everyone on the team can be good enough at pairing to reap the benefits.

Many objections about team speed miss two important points:

  • software development isn’t primarily about speed, it’s about quality and lowering the total cost of ownership of your software over time; and
  • many teams aren’t going as fast as they think they are without pairing, because they kick problems (like bugs) down the road instead of dealing with them before they become issues.

In our experience, pairing can increase team efficiency and quality. We’ll trade that for a near-term speed bump while developers on the team increase pairing skills.

“Developers don’t/won’t like it.”

This depends on the developers.

There is no denying that some developers detest pairing. They’ll quit rather than do it. If you have enough developers like that, you can choose not to use pairing. You might want to consider, though, why your developers are so opposed.

We often find that opposition comes from two common sources: developer arrogance and fear.

Genius jerks are common in software development. They believe they’re better than others, and being forced to pair with developers of lesser skill damages the genius’s ability to produce. They may be right. Perhaps they really are that much smarter than the rest of your team. Then again, maybe they’re unjustifiably arrogant. Pairing should prove which it is. Nothing humbles a developer like having a pair point out something he missed, or hasn’t thought of, or is mistaken about. If you have arrogant team members, it might be time to encourage them to move on.

Fear is every bit as common. Writing code is hard. It can be challenging to keep current on everything you need to know. No one wants to be embarrassed, so developers often use solitude as a defense. If nobody sees your code, nobody can judge your code before you want them to do it. But do you really want terrified developers on your team, or do you want a team of people who build each other up and become more confident over time? We’d rather have the second one.

“Pairing on everything wastes time.”

Agreed, so don’t. Pair when it makes sense. Don’t pair when it’s not smart to do so. For example, pairing on research doesn’t make sense. Split up, research, then come back together to compare notes. That’s a good use of time.

We’ve never recommended pairing on every task. Sometimes you don’t even have to pair when writing code, although we very rarely release any code without two sets of eyes on it, either via pairing or code review after the fact. Objecting to pairing because it’s not a good activity for some tasks is objecting to pairing done wrong. We object to that, too, but doing it wrong isn’t the only option.

“We have developers with different skill levels.”

We’d be first to admit that a team with large skill disparities can have trouble pairing effectively. You’ll typically end up with essentially a driver and a passenger, or maybe a backseat driver (where the navigator tells the driver what to type). Neither situation is good in the long run.

This can be a temporary problem, though. Those with lower skill will raise their skill level over time. It doesn’t happen overnight, but pairing with those of a higher skill level can ramp up people’s skills rapidly, much faster than sitting in a classroom. That will pay off for the team, maybe sooner than you think.

Note that this assumes your higher skilled people are good teachers. That’s not a given. If they are, your team can probably handle the wide gap in skill levels. If they’re not, the team could suffer.

“We can’t force developers to pair.”

Managers often say this, and it’s true. Some people refuse to pair. Managers shouldn’t dictate pairing as “the way we’re going to do things from now on.” It probably wouldn’t work if they tried.
That said, a smart manager might drool over the potential benefits of pairing and wonder how to get folks to do it. The short answer is that you can’t force anything. Here’s where you face a decision, and what you do depends on your role:

  • If you’re a leader with enough pull to make it happen, you can select people from your existing teams who want to pair and make a pairing team full of folks who like to work that way. Maybe their results will be so great that other jealous teams might make the switch.
  • If you’re a manager without much influence, you can encourage developers to pair.
  • If you’re a developer who wants to pair, but your team is full of people who don’t want to, you can try to change their minds, or you can change your team.

If you think pairing when it makes sense is the right way to go, you may have to fight for it.

Beyond objections

Pairing won’t magically fix what ails a team. It’s not the wisest approach in certain situations. It’s not something every programmer wants to do. It’s also not something management can impose on unwilling participants. No silver bullet here.

That said, we favor pairing over the other approaches because it tends to maximize communication efficiency, maximize code design quality, and minimize rework. If you’re interested in those things, try pairing when it makes sense (which might be more often than you think). The results might surprise you.