Stories about Software


Pair Programming Benefits: The Business Rationale

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their Retrace product that consolidates all of your production monitoring needs into one tool.

During the course of my work as a consultant, I wind up working with many companies adopting agile practices, most commonly following Scrum.  Some of these practices they embrace easily, such as continuous integration.  Others cause some consternation.  But perhaps no practice furrows more brows in management than pair programming.  Whatever pair programming benefits they can imagine, they always harbor a predictable objection.

Why would I pay two people to do one job?

Of course, they may not state it quite this bluntly (though many do).  They may talk more generally in terms of waste and inefficiency.  Or perhaps they offer tepid objections related to logistical concerns.  Doesn’t each requirement need one and only one owner?  But in almost all cases, it amounts to the same essential source of discomfort.

I believe this has its roots in early management theories, such as scientific management.  These gave rise to the notion of workplaces as complex systems, wherein managers deployed workers as resources intended to perform tasks repetitively and efficiently.  Classic management theory wants individual workers at full utilization.  Give them a task, have them specialize in it, and let them realize efficiency through that specialty.

Knowledge Work as a Wrinkle

Historically, this made sense.  And it made particular sense for manufacturing operations with global focus.  These organizations took advantage of hyper-specialty to realize economies of scale, which they parlayed into a competitive advantage.

But fast forward to 2017 and think of workers writing software instead of assembling cars.  Software developers do something called knowledge work, which has a much different efficiency profile than manual labor.  While you wouldn’t reasonably pay two people to pair up operating one shovel to dig a ditch, you might pay them to pair up and solve a mental puzzle.

So while the atavistic aversion to pairing makes sense given our history, we should move past that in modern software development.

To convince reticent managers to at least hear me out, I ask them to engage in a thought exercise.  Do they hire software developers based on how many words per minute they can type?  What about how many lines of code per hour they can crank out?  Neither of these things?

These questions have obvious answers.  After I hear those answers, I ask them to concede that software development involves more thinking than typing.  Once they concede that point, the entrenched idea of attacking a problem with two people as wasteful becomes a little less entrenched.  And that’s a start.

A Look at Pair Programming Benefits

But a start hardly means enthusiastic acceptance.  Really, it just means that they no longer shout, “balderdash” when they hear someone suggest the notion.  They’ll have a conversation, but they still need convincing.

To make further progress with management requires a business justification.  This holds especially true for management from more old school or traditional backgrounds.  These folks tend to view programming as if it looked like manufacturing or construction.  To win them over, you need pragmatic, dollars-and-cents arguments.  In other words, from a business perspective, what are pair programming benefits?

Let’s take a look at tangible rationales that you can offer for adoption of the practice.

Defect Reduction via Inspection

Have you ever read Steve McConnell’s Code Complete?  If not, I highly recommend it for both programmers and people in and around the business of programming.  The former will extract more value from it, but the book has wisdom for everyone.

One fascinating lesson from the book involves a study about defect reduction strategies, described here.  Code review has extremely high efficacy for eliminating defects — higher even than automated testing.  Now, let’s take that lesson and extend it a bit.

You can think of pair programming, in some sense, as protracted code review.  Except, rather than happening once per day/week/release, it happens continuously.  As a result, you can expect significant defect reduction per commit from a pair.  Humans catch each other’s mistakes quite effectively.

As a business, you can project ROI by estimating cost of defects and degree of defect reduction.

Cross Pollination (Increased Bus Factor)

Speaking of financial business concerns, have you ever contemplated the departure of a critical team member?  Many organizations have a person who I’ll call Alice.  Alice is a rock star who knows every nook and cranny of the codebase.  In fact, it seems as though only she can reliably make things happen in half of the codebase.  Should Alice leave, her departure would cripple the team.

Well, this situation has a cost, and businesses express that cost with a macabre metaphor: bus factor.  Simply put, this is the number of team members that a bus would have to run over before progress on their work came to a halt.  In less gruesome terms, you might also call it the “hit the lottery” factor.  Either way, it has the same implication.

Pair programming alleviates this very real, very palpable business pain.  If team members pair regularly, the bus factor grows to a nice, robust number as team members cross-pollinate their knowledge.

Increased Onboarding Efficiency

Let’s now look at another interesting benefit of team member cross-pollination.  Not only does pair programming reduce the risk posed by a departing team member, but it also improves efficiency for onboarding a new one.  Yes, pair programming benefits include making it really easy to onboard newbies.

I’ve seen teams where it took months for a new team member to do anything passingly useful.  Existing folks spent all of their time putting out fires, so newbies had to learn on their own.  And the codebases were so complex and fraught with weird, risky constructs that self-taught newbies didn’t get their hands dirty for a long time.

Pair programming completely eliminates that problem when adopted as a norm.  In fact, these teams make the ideal situation for new programmers.  Standard operating procedure would call for them to sit with experienced pair programmers on day one and immediately start doing useful things.  The difference in efficiency of navigating the learning curve will amaze you.

Reduced Distraction and Interruption Cost

I’ll offer one final benefit of practice that many might not consider at first.  I say this because many would consider pair programming inherently distracting.  You sit there with another human being that might interrupt your train of thought and prevent you from entering a state of flow.  That’s true enough.

But consider this from another angle.  The pair partner might stop you from entering a deep state of pondering, but he will also prevent you from opening Facebook and mindlessly scrolling through updates.  The two of you will stay focused on the task at hand.

And then you have the subject of interruptions, the bane of a programmer’s existence.  Consider that people performing random drive-by distractions are far more hesitant to interrupt two people than to just tap one on the shoulder.  Even in the situation where the interrupter is undeterred, one of the pair can deal with the interruption while the other remains focused.  Context-switching murders productivity.  So having at least one of the pair stay focused helps a great deal.

Apply as Makes Sense

Is pair programming always worth the investment?  Should team members pair all of the time or some of the time?  Exactly how much benefit will you realize from pairing?  I can’t answer all of these questions.

Team productivity and project cost encompass a dizzying number of variables, and contexts vary widely from case to case.  I haven’t written this post to stump for pair programming as a silver bullet.  And honestly, I haven’t even written it to stump for pair programming at all.

Instead, I wanted to point out that the practice does in fact have tangible benefits. You can’t dismiss the notion as simply as you could the idea of having two people use one shovel to dig one hole.  Experiment with the practice, learn how it fits into your team, and take advantage of it to your benefit in a way that makes sense for you, specifically.

newest oldest most voted
Notify of

A decent article, though I’m still unclear how to quantify the value/cost/ROI of pair programming in a way that wont be perceived as me “cooking numbers” just to push my (perceived) pet process. That said, a bigger underlying problem exists. Starting with the “Bus Factor”, I used to think that that was a very solid argument for several things that my team should be doing, but it turns out that management doesn’t see the loss of what we consider a “key” dev to be a problem. This is due to something you’ve described before and many of us in the… Read more »

Erik Dietrich

The trouble with writing a generalized post is that getting more concrete about numbers for the business case requires more specifics on the situation in question. Still, even with that, you could still be accused of, as you put it, “cooking the numbers.” But I’d just lean into it and admit it, though I’d reframe it as simply building a business case. I can’t think of any projections of future ROI that don’t rely on unproven or unprovable assumptions. I mean, take something as blue chip as putting money into a savings account and earning a bit of interest. That’s… Read more »

HotRod McPlunder
HotRod McPlunder
Helton Moraes
Helton Moraes

Once in a lecture the speaker talked about the “Scissors Metaphor” for pair-programming: if you imagine each individual as being the blade of a scissors, you could argue that, despite each blade separately could be used for cutting, you get a much better result if you assemble those blades and use them for shearing. The point is: a scissor is not just two blades, it’s a new, qualitatively different object altogether. The same would apply to a programming pair: the change in efficiency is not quantitative, but instead is qualitative.

HotRod McPlunder
HotRod McPlunder

Helton, I really like that analogy. Thanks for sharing it.

Erik Dietrich

Wow, that’s a great way to explain it!


How does this work with TDD? I have experience that when somebody is looking on my screen, it is almost imposible to catch for him what I have done (even if I clicked on something with mouse, not talking about keyboard shortcuts).
But maybe this is short-sighted, maybe, if you put test on one half and always projected, then you can be switching to other window on other half (and creating files) without much of distraction.

Erik Dietrich

A lot of shops that routinely pair program also practice TDD (since both are foundational planks of the Extreme Programming movement). I think a good way to handle this, pairing or not, is to have dual monitors with one containing the prod code and another containing the test code. There are also TDD-specific pairing techniques, such as so-called “ping pong pairing,” where one person writes the unit test and the other person makes it pass.


Could your draw a comparison between scientific management practices and greedy algorithms? Under the right conditions (repetitive/reproducible work) it produces optimal outcomes but in other cases (knowledge work) it falls far short of optimal.