Pair programming sounds like paying two salaries for one job. The research says the trade is more subtle: two people write code about 15% slower, but with about 15% fewer defects and a lot more shared knowledge. Whether that's a good deal depends entirely on what they're building.
Key Takeaways
- In Laurie Williams's controlled study, pairs took about 15% more time but produced about 15% fewer defects (Cockburn & Williams).
- Paired code was also more concise, and the work was rated more enjoyable.
- The 15% time cost is often cheaper than the bugs it prevents, but not always.
- Pairing pays off most on hard, high-stakes, or knowledge-transfer work, not routine tickets.
What the Research Found
The foundational study comes from Laurie Williams at the University of Utah in 1999, later written up as "The Costs and Benefits of Pair Programming" (Cockburn & Williams). Two programmers sharing one screen spent roughly 15% more total person-hours than a solo developer on the same task. In exchange, their code had about 15% fewer defects, was more concise, and the programmers reported enjoying the work more, at statistically significant levels.
Do the math and the 15% starts looking cheap. A defect caught while two people are typing never becomes a bug report, a debugging session, a production incident, or a customer email. Given how much more expensive bugs get the later you find them, trading 15% more development time for 15% fewer defects is often a bargain, because the defects you prevent would have cost far more than 15%.
But Not for Everything
Here's where teams get it wrong: they either mandate pairing for everything or ban it entirely. Both waste the tool. Pairing two seniors to knock out routine CRUD tickets burns money for little gain, the work was never going to have many defects and needed no knowledge transfer. The payoff shows up on a different kind of work. A 2009 meta-analysis of pairing studies sharpened the point: pairing tends to improve quality and speed, but the effect depends on task complexity, bigger quality gains on hard tasks, bigger time costs on easy ones (Hannay et al., 2009).
| Work type | Is pairing worth it? |
|---|---|
| Routine, low-risk tickets | Usually not |
| Gnarly, high-stakes logic | Yes, defects are costly |
| Onboarding / knowledge transfer | Yes, the second seat is teaching |
| Critical path only one person knows | Yes, it kills the bus factor |
A Concrete Version
A payments team has one engineer who understands the reconciliation logic and a nasty edge-case bug to fix in it. Solo, that's a risky change in code only one person groks, and if they get it wrong it's a money bug. Pair them with a second engineer for two days. Yes, it "costs" two people for work one could technically do. But the change gets a real-time review as it's written, the fix is likelier correct the first time, and a second person finally understands reconciliation, so the bus factor just went from one to two. That's the 15% buying three things at once.
The Honest Counterpoint
Pairing isn't free beyond the 15%, and it isn't for everyone. It's genuinely draining, eight hours of pairing exhausts most people far more than eight hours solo, so all-day-every-day pairing burns people out. It also clashes with deep, exploratory work where one person needs to sit and think. And remote pairing adds friction that co-located pairing doesn't. Treat it as a scalpel, not a policy: pair on the hard and the high-stakes, solo on the routine, and never force it as an all-day mandate.
Where It Fits a Distributed Team
Pairing is one of the fastest ways to transfer context, which makes it especially useful when you add engineers, whether new hires or augmented senior staff. A few days pairing a new engineer with an owner does more than a week of reading docs, and it's part of how good onboarding works. It also directly attacks the knowledge-silo risk we cover in code ownership and software quality, spreading context so no single person is the only one who understands a critical system. See available engineers.
Frequently Asked Questions
Is pair programming worth the cost?
Often, yes. The classic study found pairs take about 15% longer but ship about 15% fewer defects. Since bugs get more expensive the later you catch them, that trade usually comes out ahead on the right kind of work.
When should you pair?
On hard, high-stakes, or unfamiliar work, and for onboarding or knowledge transfer. Routine, low-risk tickets rarely justify two people.
When should you not pair?
On routine work, on deep solo-thinking tasks, and as an all-day everyday mandate, which exhausts people. Pairing is a scalpel, not a blanket policy.
Does pair programming help remote teams?
Yes, especially for transferring context fast and reducing knowledge silos. It adds some remote-tooling friction, so use it deliberately rather than constantly.
The Bottom Line
Pair programming isn't two salaries for one job; it's a 15% time cost that buys 15% fewer defects plus shared knowledge. On routine work that's a bad trade. On hard, high-stakes, or siloed code, it's one of the best deals in engineering. Use it where the defects are expensive and the knowledge is scarce, not everywhere.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
