Pair programming and code review are not substitutes for each other. Pairing puts two developers on one task while the code is being written. Code review examines a change, usually once it is prepared, and often with people who did not write it. A team that treats one as a replacement for the other tends to misjudge what each is for. The useful question is which function the work needs: live shared reasoning, an independent second look, or both.
How the two practices differ
The two practices overlap in purpose, since both aim to produce better code and spread understanding across a team, but they operate at different points in the development cycle and involve different kinds of interaction.
| Aspect | Pair programming | Code review |
|---|---|---|
| When it happens | During implementation, while the code is being written | After a change is prepared, typically before it is merged |
| Who is involved | Two developers sharing one task | The author plus one or more reviewers, who may not have touched the code |
| Interaction | Synchronous and continuous | Often asynchronous and tool-supported, with discussion held around the change |
| Stated purpose | Shared problem solving and feedback as work happens | Inspection of a change. Defect finding is the most common motivation, but studies report other outcomes too |
| Knowledge sharing | Spreads understanding of the code as the work happens | Transfers knowledge, builds team awareness, and surfaces alternative solutions |
| Main costs | Two people’s attention at once, scheduling, and interpersonal fit | Reviewer time and the effort needed to understand the change |
| Strength of the evidence | Mixed and dependent on task type; most studies are small or dated | Largely drawn from one large company’s 2013 study; direct comparison with pairing is limited |
What the evidence says about pair programming
Most of the pairing evidence is between ten and twenty years old. It is useful for describing benefits and trade-offs, but it does not measure how common pairing is today.
Perceived benefits and costs in industry (2008)
Andrew Begel and Nachi Nagappan surveyed Microsoft engineers in 2008. The survey was sent to a randomly selected 10% of Microsoft engineers, and 22% reported that they had pair-programmed. That figure describes one company in 2008, not current industry adoption.
Respondents named three main benefits. In the words of the paper’s abstract, “The biggest perceived benefits of pair programming were the introduction of fewer bugs, spreading code understanding, and producing overall higher quality code.” The top problems were different in kind: “cost-efficiency, (work time) scheduling problems, and personality conflicts.” Engineers also said they preferred partners who had complementary skills, were flexible, and communicated well.
What the meta-analysis found (2009)
A meta-analysis published in Information and Software Technology in July 2009 pooled 18 pair-programming experiments. It found a small, statistically significant average benefit to quality, but the studies varied widely. Its authors concluded that “pair programming is not uniformly beneficial or effective, that inter-study variance is high, and that perhaps publication bias is an issue.”
The subgroup results add nuance. As the abstract describes them, pairs finished faster than solo developers on low-complexity tasks, while higher quality on complex tasks came with greater effort. Reduced completion time on simpler tasks was accompanied by lower quality. These are patterns across studies, not a prediction for any particular team.
A student-team study (2008)
A University of Dortmund study published in Information and Software Technology in February 2008 involved 13 teams and about 100 students. Paired teams produced nearly as much code as solo teams while using twice as many workstations, and the paired code was easier to read and understand. Because the participants were students, the result describes an educational setting and should not be read as evidence about professional teams.
Rank #3
What the evidence says about code review
The most detailed recent account of review outcomes comes from Christian Bird and Alberto Bacchelli, whose study of Microsoft reviews was published in 2013. Their abstract states: “while finding defects remains the main motivation for review, reviews are less about defects than expected and instead provide additional benefits such as knowledge transfer, increased team awareness, and creation of alternative solutions to problems.”
That finding changes how reviews should be judged. A review that never catches a defect may still have done its job if it moved knowledge across the team or produced a better design. Because the study covers one company, the proportions it reports should be treated as one organization’s experience.
The direct comparison, and its limits
The closest match to the question is a pair of controlled experiments comparing pair programming with peer review, published in the Journal of Systems and Software in 2005. The accessible abstract gives limited outcome detail. It also states that its small tasks could not capture long-term benefits. The experiments therefore do not show that review is equivalent or superior to pairing in general, and they do not show the reverse.
Three claims the evidence does not support
- Pairing always improves productivity. The meta-analysis found it is not uniformly beneficial, and its subgroups show that speed and quality can pull in opposite directions.
- Code review exists only to find bugs. Defect finding is the main stated motivation, but the 2013 study found that reviews deliver knowledge transfer and team awareness as well.
- Either practice makes the other unnecessary. The studies describe distinct functions, and none tests a rule that one can replace the other across teams.
Choosing between pairing, review, or both
The distinct functions suggest a simple way to decide. Start with the job the change needs done, then choose the practice that does that job. The guidance below is a practical reading of the evidence, not a rule established by controlled trials.
Best Value
Pair when shared reasoning is the bottleneck
- The task is complex or uncertain, and the developer benefits from continuous discussion while designing the solution.
- A team member needs close, hands-on context on a part of the code they do not yet know.
- The team wants to build shared understanding of a module before others depend on it.
Plan for the costs the survey respondents reported. Schedule two people for the same task, and choose partners who communicate well and can work flexibly together.
Review when an independent perspective is the goal
- Someone outside the work needs to check assumptions the authors may share.
- Reviewers can respond asynchronously, and the discussion needs to stay attached to the change.
- The team wants knowledge to spread beyond the people who wrote the code.
Use both when each function matters
Combining the practices makes sense when live collaboration helps produce the work and another reviewer can still add meaningful independent context. The evidence supports the distinct roles of each practice, but it does not establish a universal threshold for when both are required.
Do not skip review because a pair wrote the change
Whether a pair provides enough independent scrutiny depends on who participated and what the change risks. Two developers who worked closely together may share the same blind spots, so a pair label alone is not a reason to bypass review. The sources do not establish a one-size-fits-all exemption either way.
Quick Recap
Further reading
- Looks Good to Me: Constructive Code Reviews by Adrienne Braganza (Manning, January 7, 2025; trade paperback, ISBN 9781633438125). It covers code-review practice and includes a chapter on how reviews relate to pair programming. This is an optional resource, not required reading.
- Collaborative Quality Assurance in Information Systems Development by Kai Spohrer (Springer, 2015). A more academic book that examines pair programming and peer code review in agile teams. Springer lists a softcover edition. According to the publisher’s description, it draws on survey responses from more than 500 respondents across 81 software-development teams.
- Pair Programming Illuminated by Laurie Williams and Robert Kessler (Addison-Wesley, 2002). Historically important for the practice, but the publisher listing reports it is no longer in print. Check retailer inventory before buying.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
