# pair-programming

**Pair programming** is the practice where two (or more) developers work on the same code at the same time, providing continuous real-time review. **Ensemble (mob) programming** extends it: the whole team works on one thing on one screen. Both are mechanisms for relocating quality work from after development to during it.

The peer-reviewed evidence for pair programming is one of the better-documented empirical bases in software engineering practice — and the comparison against solo+review is the empirical hinge for arguments like [[stop-using-pull-requests]].

## The studies

- **Williams et al., 2000** — *"Strengthening the Case for Pair Programming"* (IEEE Software). Pairs produced **15% fewer defects** than solo developers.
- **Hannay et al., 2009** — *"The Effectiveness of Pair Programming: A Meta-Analysis"* (Information and Software Technology). The most comprehensive meta-analysis to date: **small significant positive overall effect on quality**, strongest on complex tasks.
- **Arisholm et al., 2007** — *"Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise"* (IEEE TSE). 295 professional developers. **48% increase in correct solutions on complex systems.** Junior developers showed the strongest benefit: **149% improvement on complex tasks**.
- **Muller & Tichy, 2005** — *"Two Controlled Experiments Concerning the Comparison of Pair Programming to Peer Review."* The key result: **pairs and solo programmers with peer review achieve equivalent cost when quality is held constant.** The review phase for solo developers adds enough overhead to match the cost of pairing.
- **Madeyski, 2006** — empirical study on design quality improvement from best-practice inspection vs pair programming.
- **di Bella et al., 2013** — *"Pair Programming and Software Defects — A Large, Industrial Case Study."*

## The Muller & Tichy claim, examined

This is the result [[stop-using-pull-requests]] leans on hardest: **pair programming does not cost more than solo + peer review** at equivalent quality. The intuitive objection — "you've doubled the developer-hours" — misses that solo+review also doubles them, just split across time and across people.

The implication, if you accept it: pairing isn't slower than the standard workflow; it's the same workload reshaped. The supposed efficiency of "developer codes alone while another developer reviews later" doesn't survive the comparison.

## The honest gap

Laforgia, who relies on this evidence heavily, names the gap clearly: **no peer-reviewed study has directly proven that teams can safely eliminate post-hoc review when practising pair programming.** The studies show:

- Pair programming produces equivalent quality at equivalent cost to solo+review.
- Pair programming catches things differently and earlier than post-hoc review.

They do not show: a team practising pair programming and *no* post-hoc review at all maintains the same quality as a team with post-hoc review on top. The argument that pairing fully replaces PRs is practitioner consensus extending the cost-equivalence finding — well-reasoned, not empirically proven.

The Muller & Tichy + Hannay meta-analysis gets you "comparable cost at equal quality." The additional step is a judgement, not a finding.

## Ensemble (mob) programming

Woody Zuill's ensemble programming extends pair programming to the whole team: one screen, one keyboard rotation, the entire team contributing. Review happens after every line. The academic evidence is preliminary, but the practitioner consensus is strong — when the whole team creates together, post-hoc inspection has little to add.

Tradeoffs:

- Knowledge transfer is maximal — every team member sees every change.
- Scheduling cost is high — the whole team is committed to one stream of work at a time.
- Best for high-uncertainty, high-value work where the alignment payoff is worth the throughput cost.
- Worst for routine work, where the team-wide attention is a waste.

## Position in the T*D triple

Laforgia ([[stop-using-pull-requests]]) groups pair/ensemble programming with TDD and [[trunk-based-development]] as **T\*D**:

- TDD builds quality in per-line before code exists.
- TBD keeps integration continuous.
- Pair/ensemble (Team-focused Development) relocates review into the act of creation.

Each leg compensates for what the others can't catch. Pair programming reviews continuously; TDD catches regressions automatically; TBD keeps batches small enough that what slips through is recoverable.

## Caveats

- **Energy cost.** Pairing well is intensive — sustained attention, communication, negotiation. Most accounts put a hard cap around 5-6 hours/day before quality drops.
- **Personality and skill fit.** Some pairs don't work. Rotating helps but adds coordination cost.
- **Distributed teams.** Pairing across timezones is degraded; pairing across overlap windows is fine. For teams with minimal overlap, async PRs may be the least-bad option.
- **Junior+junior pairs.** The 149% Arisholm number was on senior pairs with juniors, not junior+junior. Two beginners pairing isn't necessarily two times one beginner.

## Related

- [[stop-using-pull-requests]] — the larger argument in which pair programming is the team-focused leg
- [[code-review-knowledge-transfer]] — what review is actually for, which pair programming delivers far better than async PRs
- [[trunk-based-development]] — the integration practice that pair programming makes viable without post-hoc gating
- [[ship-show-ask]] — the transitional model for teams not ready to pair on everything
- [[programming-as-theory-building]] — Naur's frame: the team's shared mental theory of the program is the primary product, which pairing builds directly