Stop Using Pull Requests

Article: Stop Using Pull Requests by Andrea Laforgia

Summary

“Inspection is too late. The quality, good or bad, is already in the product. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”
— W. Edwards Deming, Out of the Crisis (1982)

The Uncomfortable Truth

A developer writes code in isolation. Opens a pull request. It sits in a queue. Someone leaves a few comments — mostly about naming and formatting. Clicks approve. Merges.

It feels like quality control. The evidence says it’s mostly theatre.

A Solution Designed for Strangers

Pull requests trace back to Linus Torvalds’ git-request-pull in 2005, a gatekeeper for open source projects — a way to safely accept code from strangers who don’t own the repository.

GitHub launched web-based pull requests in 2008. And teams everywhere copy-pasted it into their internal processes — not because they evaluated it, but because it was there.

“Pull requests are designed to make it easier to accept contributions from the outside world, from untrusted people we do not know about.” — Thierry de Pauw

The category error: in your team, you are reviewing code from a colleague in the same stand-up, with the same goals, hired because you trust their competence. Yet the process is identical to reviewing a stranger’s patch.

“Pull requests are an improvement on working alone. But not on working together.” — Jessica Kerr (amplified by Kent Beck)

What Code Review Actually Finds

Most teams justify PRs as a bug-catching mechanism. Research says otherwise.

What code review comments are actually about:

  Style & structure   ████████████████████████████████████  ~85%
  Actual bugs         ████                                  <15%

A 2015 Microsoft Research IEEE study found the majority of comments relate to structure and style — not bugs
A landmark 2013 Bacchelli & Bird study (Microsoft): “reviews are less about defects than expected” — primary benefits are knowledge transfer and shared awareness
Analysis of 1.5 million review comments: the more files in a change, the lower the proportion of useful comments
One major tech company, after examining 9 million code reviews: cited knowledge transfer — not bug-finding — as the primary source of ROI

The value is real — but it’s in the wrong place. If you’re using PRs primarily to catch bugs, you’re optimising for a benefit that peer-reviewed research says is marginal.

The Staggering Cost of Waiting

  Change takes 10 min to write...

  Waits 1 hour for review    →  86% of lead time is waiting
  Waits 4 hours for review   →  96% waiting
  Waits 1 working day        →  99% waiting

Real numbers from a real organisation:

130,000 hours spent in 2020 waiting on pull requests (a client cited by Martin Fowler)
91% of those PRs received zero comments
The vast majority were rubber-stamped — yet the delay was still enormous

Context switching makes it worse:

Average wait for a PR review: 4 days
86% of PRs handled under context-switching conditions
Context-switching PRs are 223% slower
Rebuilding mental context after switching: 30–60 minutes

The financial reality (Charity Majors):

Team size	Deployment cadence	Staff needed to match a continuous-delivery team
6 people	Days to deploy	~~24 people (~~$3.6M in unnecessary salary)
10 people	Weekly shipping	~~80 people (~~$14M in waste)

The Vicious Cycle of Async Review

Because the cost of getting a review is high, developers batch more changes into each PR to amortise it.

  High PR transaction cost
          ↓
  Developers batch more changes
          ↓
  Larger PRs → longer, less effective reviews
          ↓
  More waiting → more WIP → less reviewer availability
          ↓
  Even more async handoffs
          ↓
  N teams of one person, not one team of N

“Instead of forming one team, developers become N teams of one person, often with different engineering cultures and coding practices.” — Dragan Stepanovic, after studying 30+ active repositories

What DORA Tells Us

Accelerate (Forsgren, Humble, Kim) — 4 years of research, 23,000+ surveys, 2,000+ organisations:

Trunk-based development correlates with higher delivery performance across every metric
High performers: fewer than 3 active branches, branches lasted less than a day, no code freezes
“Heavyweight code review processes” explicitly identified as a barrier — they push developers toward larger batches

2023 State of DevOps Report (36,000+ professionals):

Accelerating the code review process alone can lead to a 50% improvement in software delivery performance.

The problem isn’t review — it’s the speed of review. Make it instant and you keep the benefit without the cost.

Note: DORA research is correlational, not causal. But the consistency across years and tens of thousands of respondents makes it the strongest industry evidence available.

A Growing Consensus

ThoughtWorks Technology Radar (April 2021): Placed “Peer review equals pull request” in the HOLD ring.

PRs create significant team bottlenecks
Overloaded reviewers begin rubber-stamping
One regulatory audit found PRs did not satisfy compliance — there was no evidence the code was actually read

Jason Gorman asks the most piercing question:

“Ask not so much ‘How do we do Pull Requests?’ but rather ‘Why do we need to do Pull Requests?’”

His answer: PRs are a symptom of low trust, not a solution for low quality.

Build Quality In

The alternative isn’t no review — it’s better review, built into the process rather than bolted on at the end.

Three practices, one philosophy: shift quality left.

Test-Driven Development

Write a failing test → write minimum code to pass → refactor → repeat.

Microsoft & IBM studies: TDD reduced pre-release defect density by 40–90%, at a cost of 15–35% more development time
Automated safety nets catch regressions immediately
When every line satisfies a test, the code is already verified before it reaches anyone

Trunk-Based Development

All developers merge to main at least daily. Feature flags manage incomplete work.

Ideal branch duration: one day maximum (Paul Hammant)
When changes are tiny, the review burden is minimal — there’s nothing large enough to fear
Daily integration to trunk is the definition of continuous integration

Team-Focused Development

Two or more developers on the same code, at the same time — continuous real-time review.

Williams et al. (2000): pairs produced 15% fewer defects
Hannay et al. (2009) meta-analysis: small but significant positive effect on quality, strongest on complex tasks
Arisholm et al. (2007): 48% increase in correct solutions on complex systems; junior devs showed 149% improvement
Muller & Tichy (2005): pairs and solo + 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 — pairing simply moves quality assurance from after development to during it.

Caveat from the article: no peer-reviewed study proves that teams can safely eliminate post-hoc review through pairing, and the evidence for ensemble programming is still preliminary.

The Transition: Ship / Show / Ask

Not ready to drop PRs entirely? That’s the right starting point.

This is Stage 2 of a gradual, evidence-based transition:

Stage 1        Stage 2          Stage 3           Stage 4          Stage 5
────────       ────────         ────────           ────────         ────────
Optimise  →  Ship/Show/  →  Pair + Trunk  →  Ensemble +  →  Full T*D
your PRs      Ask                              Trunk

SHIP — Just merge it

“I know what I’m doing. This is safe.”

Commit directly to mainline — no PR, no waiting
CI/CD validates automatically
Best for: refactors, dependency bumps, config changes, obvious fixes

SHOW — Merge now, discuss later

“Here’s what I did — thoughts welcome!”

Open a PR, but merge immediately without waiting for approval
Team reviews and comments after it’s live
Best for: new features, experiments, changes worth documenting

ASK — Let’s talk before merging

“I’m uncertain — I need your input.”

Open a PR and wait for a conversation — not approval, conversation
Best for: architectural decisions, risky changes, unfamiliar territory

Ship/Show/Ask was developed by Rouan Wilsenach and published on martinfowler.com

Trust Is a Gradient

The case against blocking PRs is strongest where trust is highest — and the article is explicit that it weakens as trust drops.

Small co-located team that pairs daily: very high trust; async PRs replace trust that should already exist
Large organisation, lower cross-team trust: lightweight PRs with fast SLAs may still be needed
Inner-source or platform teams taking semi-external contributions: a gatekeeper model fits, kept fast and non-blocking
Distributed teams: pair in the timezone overlap, review post-commit otherwise; with minimal overlap, use async PRs but keep them small, with a 4-hour SLA and one reviewer

Start This Week

Audit your last 20 PRs — how many had meaningful comments? How long did they wait?
Agree on a Ship/Show/Ask taxonomy with your team
Identify 3 change categories that can be Shipped directly (docs, tests, minor refactors)
Track cycle time before and after — let the data do the convincing
Make PRs smaller and faster — under 200 lines, 4-hour review SLA, one required reviewer

“The question is not ‘How do we do pull requests better?’ The question is ‘Why do we still need them?’”

Ship/Show/Ask: martinfowler.com