You already wish you had more budget for custom code. An hour of a programmer’s time costs a lot; in some cases it approaches the hourly rate of lawyers. So if your programmers pair program, that cuts the amount of code your programmers crank out per hour in half...doesn’t it?

It doesn’t. This is why.

Because writing custom code is not a process of cranking it out. You’re asking for custom code because you want something specific to your organization—that is, something that has never been done quite this way before.

In addition to the fact that you want something unique, the plethora of languages, libraries, frameworks, and tools that programmers use to make your features are always changing. If a programmer steps out of programming for eight months, her skills become obsolete. She isn’t useless, but she’s out of date on every single language, library, framework, and tool she is asked to use upon her return. That’s how fast this industry changes.

Programmers aren’t cranking out the same thing day after day; instead, they are constantly learning new things on the job.

But the learn-and-apply process is not linear. It involves experimenting, making mistakes, trying things several times with a different variable isolated each time.

…and there’s more than one solution to most of the problems programmers need to solve.

And that’s why pair programming isn’t half as efficient as solo programming; most of a programmer’s day is spent applying new knowledge to previous experience, and two programmers can do that together better than one programmer can do it alone.

Why does pair programming help with this?

1. Pairing reduces the amount of time developers spend on poor solutions. When programmers are trying something new, they have to make guesses. Sometimes, they’re several hours into your first proposed solution before they realize that this isn’t going to work. Now they have to back out all of that code and try something else. More often than you realize, your programmers spend two days on a giant refactor and end up undoing the whole thing. If they’re savvy, they committed the code before they started the experiment, so backing it out only takes a second. Just as likely, they didn’t commit at the last point where they wanted to keep the code, so they have to back out manually—which can take almost as long as writing the code in the first place. When programmers are pairing, though, one pair can think about the future implications of their solution while the other pair stays in the weeds writing the methods and variables. The first pair can spot problems earlier and help the second pair steer clear of them, like a sailor in a crow’s nest communicating with the person driving the ship.
2. Pairing guards against cognitive biases. One pair can hold the other pair accountable to time-boxing their solution, so that if things aren’t working out after an hour they’ll try something else. When a programmer solos, it is easy to get emotionally invested in a solution. They want it to work out. They can also become a victim of the sunk cost fallacy—they have already sunk so much time into this solution that they feel obligated to see it through. However, their pair is in a better position to see through these biases. Their pair can see things from further away and recognize when additional time spent might be wasted. Sometimes, it takes an outside voice to convince a programmer to move on to the next thing. Or sometimes, a programmer realizes while explaining an idea that it doesn’t sound as good out loud as it did in their head. This saves hours and days of pursuing poor solutions.
3. Pairing lets programmers try more new things faster. Two developers have different experiences and perspectives that they can apply to the problem at hand. While one types and thinks about the current solution, their pair can assess alternatives. When they and their pair know different languages, libraries, and frameworks, they spend less time looking up how to do things because they can lean on each other’s experiences. Where one programmer might alight on a lengthy, complex solution, another programmer knows a simple implementation that could do the same thing. When they bring two spheres of experience to bear on a problem, the likelihood doubles that they’ll fin the simple solution instead of the complex one—which saves tons of time for programmers in the future, too, when it’s time to change the existing code for this feature.
4. Pairing facilitates shared context, so your team doesn’t get blocked on one person. If you have participated in app development before, you’re familiar with this predicament: something needs to get done, but one specific person knows how to do it…and for whatever reason, that person is not available until next Tuesday. Your project ends up progressing much slower than it should because a critical feature has to wait. You feel powerless and trapped, and you worry that a stakeholder will slam you for being behind schedule. Pair programming decreases the risk of this happening because it ensures that multiple people on your team were present for everything that your team has ever done. That way, if one of those people is out, the other one has context on the solution that they built together.

Does pair programming make sense for your team?

Maybe all of this makes sense in theory, but you still can’t imagine how six programmers working on three features could make more sense for your project—or your pocketbook—than six programmers working on six features.

You can roughly measure the factors we talked about above with three numbers. You’ll ask your programmers to record these numbers each time they finish a feature, complete a refactoring chore, or fix a bug. They’ll sum up their totals for a daily team metric, then they’ll sum up the daily totals after a week or two.

Once that week or two has passed, take a look at the results. We’ll talk about how to measure those results in a second. Here is the assessment:

• I spent ___ hours stalled on this work because of what turned out to be a typo or something that I misread in the logs.
• I spent ___ hours experimenting with solutions for completing this piece of work.
• Out of the solutions I tried, the one solution that I ultimately committed took me ___ hours.

After a couple of weeks, add up how many hours were logged for each of the bullets. If the total for the first bullet is more than a quarter of total development time, the you have a strong case for trying out pairing. This happens frequently during bug fixes and building network calls, but the chances of a pair of programmers repeatedly missing a detail by reading too fast are much lower than the chances of one programmer doing it.

Also, if the total for the second bullet is more than twice the total for the third bullet, then you have a case for trying out pair programming. Pairing will not eliminate the need to experiment with different solutions, but it will cut down on the amount of time spent pursuing solutions that won’t work out.

Pairing is not always the answer

There are situations where soloing makes more sense for your team than pairing does.

• If your development team has three programmers or fewer, then the code base might not be growing fast enough for you to require the benefits of pairing. Additionally, on a team this small, the relatively small amount of context being generated is easier for team members to pass among one another during regular daily conversations. You do, however, need to make sure that those daily conversations are happening.
• If none of your developers know anything about the stack or framework in which they are building this application, then there will be a lot of Googling and not much context for your developers to build on each other’s ideas. They’ll be better off moving at their own pace—which will be slow—and sharing what they have done with the team at the end. For a pair to be productive, at least one of the programmers needs to be somewhat familiar with the language the pair is writing.
• If one of your developers is a jerk, please do not make your other programmers pair with them. Your other developers will become demoralized, and they might quit. In fact, if one of your developers is a jerk, get rid of them. Full stop. I don’t care how talented they are or whatever; they’ll drag your team backward in a hundred ways that you will never see. When you get rid of them you’ll find that your team miraculously recovers the loss of whatever knowledge the jerk had siloed away.

In Conclusion

Pair programming does not cut your team’s development productivity in half because pairs of programmers can solve new (or partially new) problems more efficiently than an individual programmer can by herself. They can identify poor solutions more quickly, avoid cognitive biases, apply new perspectives together, and share context on all of the code among the team. Pairing might not be the best choice for you if your team is tiny, or no one knows the language or framework, or you have a jerk on board. However, you can ask a few questions and add up the answers over time to figure out if pair programming might be worth a try for your organization.

For more on how to pair program really well, check out the post series on Advanced Pair Programming:

• Pairing Remotely
• Enabling Your Pair
• Learning From Your Pair