Pair Programming: When It Works and When It Doesn't
Updated: Oct 19
A team adopts pairing for all production code after a bad quarter of escaped defects. Three months later, delivery has slowed noticeably, two senior engineers are quietly working solo in the evenings to get through routine tickets, and nobody can say whether defects have dropped, because nobody measured them before or after. The policy survives on belief, and so does the backlash against it.
This is a composite, and both sides of that team's argument were partly right. The evidence on pairing doesn't say "always" or "never". It says pairing pays when the task is hard for the people doing it, and costs extra effort when it isn't. This post shows what the research found, how to decide task by task, and how to find out whether pairing is working on your team.
What the largest experiment found
In 2007, Arisholm, Gallis, Dybå and Sjøberg published one of the largest controlled experiments on pairing. They hired 295 professional Java consultants (99 working alone and 98 pairs) from 29 consultancies in Norway, Sweden and the UK for a day, and gave them change tasks on two systems, one simpler and one more complex.
Across everyone, pairing didn't reduce the time to solve tasks correctly or raise the share of correct solutions, and it increased the effort to do the tasks correctly by 84%. But the averages hid two opposite effects:
System | Effect of pairing | Who benefited most |
More complex | 48% more correct solutions, no significant change in time | Mainly juniors |
Simpler | 20% less time, no significant change in correctness | Mainly intermediates and seniors |
Overall | 84% more effort to reach a correct solution |
The authors note that the benefits may be larger for bigger, more complex tasks and for pairs who work together over a longer period than one day. Even so, the pattern is clear. Pairing's value depends on how hard the task is relative to the expertise of the people doing it. A policy that ignores that pays the effort cost everywhere and collects the benefit only in some places.
The test: for your team's last ten tickets, how many were genuinely hard for the people who did them? That's roughly the share of work where pairing is likely to pay for itself on correctness alone.
Decide per task, with three questions
Instead of a policy, use a quick decision before each piece of work:
Is this hard for the people who'd do it? Unfamiliar code, a subtle bug, a design choice with long consequences, or a junior engineer on a complex part of the system. This is where the experiment found the correctness gains.
What does a mistake cost? Payments, authentication, data migrations and irreversible changes justify a second person's time even when the task isn't hard, because the cost of an escaped defect is far higher than the extra effort.
Is there knowledge that needs to spread? Only one person understands this service, someone new is joining, or two specialists need to build something across their boundary.
Hard for this pair? | Mistake expensive? | Knowledge to spread? | Decision |
Yes | Any | Any | Pair |
No | Yes | Any | Pair, or solo with a thorough review |
No | No | Yes | Pair for part of it, with the learner at the keyboard |
No | No | No | Solo, normal review |
The test: before the next sprint, run the three questions on each ticket and mark which ones you'd pair on. If the answer is "all" or "none", look at the tickets again.
Hand the keyboard to the person learning
The textbook model of pairing has a driver who types and a navigator who thinks ahead. When Chong and Hurlbutt spent four months observing professional pairs on two teams, they didn't see that. The pairs moved through the task together, discussing issues at the same level of abstraction and largely in the same role, switching keyboard control often.
They also found that the difference in expertise between the two people had a strong influence on how the pairing went, and that whoever held the keyboard had a consistent effect on decisions. That has a practical consequence. When an expert holds the keyboard, the expert tends to make the decisions and the other person watches. When the person learning holds it, they have to make each move, and the expert's job becomes asking questions and catching mistakes.
So for onboarding and knowledge transfer, put the less experienced person at the keyboard on the hard part of the work, not the easy part. The experiment found juniors gained most on complex code, which is the code most teams keep away from them.
The test: after your next onboarding pairing session, ask who held the keyboard for most of it, and who made the main design decisions. If both answers are the senior engineer, the session transferred less than it could have.
When pairing goes wrong
The common failures follow from the same evidence:
Routine work, paired anyway. On simple, well-understood tasks, the experiment found time savings mainly for experienced developers and no correctness gain, at a large effort cost. A mandate to pair on everything pays that cost on every routine ticket.
One person takes over. A large expertise gap, combined with the expert holding the keyboard, turns the session into a demonstration. The other person disengages and learns little. Swap the keyboard, or swap the pair.
Work that needs long, quiet concentration. Some problems need hours of uninterrupted thought. Pair on framing the problem and on reviewing the result, and work solo in between.
Nobody can stop. If the problem turns out to be simple, or both people are tired, split up. Pairing is mentally demanding; treat a couple of hours as a full session and take a break before deciding whether to continue.
The test: ask the people on your team who pair most what fraction of their paired time felt like one person working with an audience. More than occasional means you need to fix the dynamic, not the policy.
Keep a pairing ledger
Most arguments about pairing are arguments about beliefs, because nobody records what happened. A lightweight ledger for a month settles them. For each piece of work, record whether it was paired, which of the three reasons applied, the effort in person-hours, and what happened afterwards:
Ticket Paired Reason Person-hrs Review rounds Defects found later
PAY-212 yes cost of mistake 9 1 0
ONB-31 yes knowledge (new) 12 1 0
API-88 no routine 3 1 0
API-91 no routine 4 3 1 (missed edge case)
SRCH-7 yes hard (unfamiliar) 14 1 0
UI-140 yes mandate 6 1 0
The figures are illustrative. After a month, compare: did paired work on hard or high-stakes tickets have fewer review rounds and fewer defects found later than similar solo work? Did paired routine work show any benefit for its extra hours? Pairing on hard work should show up in the last two columns. Pairing on routine work will mostly show up in person-hours.
The test: after four weeks, can you point to at least one category of work where pairing measurably reduced rework or escaped defects, and one where it didn't? That's your team's pairing policy, written from your own data.
Remote pairing
Remote pairing works with shared editing (VS Code Live Share or a dedicated pairing tool) or plain screen sharing. Clear audio matters more than video. Many pairs turn the camera off and keep the screen and voice. Shared-editing tools that give each person their own cursor make it easy to pass control back and forth, which supports the frequent keyboard switching Chong and Hurlbutt observed. If the connection is laggy enough that one person is always behind, use a short call to frame the problem and then switch to an asynchronous review.
A worked example
Here is the composite team from the opening, after a month with the three questions and a ledger. The figures are illustrative.
Before: pair on all production code (3 months)
Delivery slowed; seniors doing routine tickets solo after hours
Defect data: not collected
Month with three questions + ledger
Tickets: 46 Paired: 15 (33%)
Hard for the pair: 6 Cost of mistake: 5 Knowledge spread: 4
Learner at the keyboard in all 4 knowledge sessions
Results (paired hard or high-stakes vs similar solo work)
Review rounds: 1.2 vs 2.1
Defects found after merge: 0 vs 3
Routine tickets paired under the old mandate (sample of 8):
no fewer review rounds, about double the person-hours
New policy
Pair by the three questions; ledger reviewed monthly in the retro
The team kept pairing where it paid, and stopped paying for it where it didn't.
What to do this week
Run the three questions on the next sprint's tickets and pair only where one applies. Start the ledger with five columns: ticket, paired, reason, person-hours, defects found later. In the next onboarding session, put the new person at the keyboard on the hardest part of their first task. Review the ledger in your retrospective after four weeks. For pairing used deliberately as mentoring, see Pair Programming That Helps.
Final takeaway
Pair programming isn't good or bad in general. In the largest controlled experiment, it raised effort by 84% overall, improved correctness where the system was complex for the people working on it, and saved time mainly for experienced developers on simple work. So decide per task: pair when the work is hard for the pair, when a mistake is expensive, or when knowledge needs to spread, and work solo with a normal review otherwise. Put the person who's learning at the keyboard, because whoever types tends to decide. Then keep a ledger for a month and let your own review rounds and escaped defects, rather than belief, set the policy.
Sources
Arisholm, E., Gallis, H., Dybå, T. and Sjøberg, D. I. K., "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise", IEEE Transactions on Software Engineering 33(2), 2007, pp. 65–86: 295 professional Java consultants (99 individuals, 98 pairs) from 29 companies; no overall reduction in time or increase in correctness; 84% increase in effort; on the complex system 48% more correct solutions, mainly for juniors; on the simpler system 20% less time, mainly for intermediates and seniors. https://doi.org/10.1109/TSE.2007.17
Chong, J. and Hurlbutt, T., "The Social Dynamics of Pair Programming", Proceedings of the 29th International Conference on Software Engineering (ICSE), 2007, pp. 354–363: four-month ethnographic study of professional pairs; pairs did not follow separate driver and navigator roles; the distribution of expertise strongly influenced interaction; keyboard control had a consistent effect on decision-making. https://doi.org/10.1109/ICSE.2007.87
Williams, L., Kessler, R. R., Cunningham, W. and Jeffries, R., "Strengthening the Case for Pair Programming", IEEE Software 17(4), 2000, pp. 19–25: an early case for pairing, reporting better products in less time and more confident programmers. https://doi.org/10.1109/52.854064
Related reading
Keep learning. This article is part of the Advanced Quality Engineering path in the ShiftQuality Learning Center. Take quality from a team chore to an organizational property.
