Your team’s code review process is probably an expensive illusion of quality. Here’s what the evidence says, and what to do instead.

TL;DR

  • Pull requests were designed for open source contributions from untrusted strangers. Applying them to trusted teams is a category error.
  • Peer-reviewed research shows code review’s primary value is knowledge transfer, not bug detection. Less than 15% of review comments relate to actual bugs.
  • Async PR workflows mean your code spends 86-99% of its lead time waiting. One organisation spent 130,000 hours in a single year waiting on PRs that received zero comments.
  • DORA research across 36,000+ professionals shows trunk-based development correlates with dramatically higher software delivery performance, and faster code reviews alone improve performance by 50%.
  • The alternative is T*D: Test-Driven Development (build quality in), Trunk-Based Development (integrate continuously), and Team-focused Development (review during creation, not after).
  • The transition is gradual: optimise PRs first, adopt Ship/Show/Ask, then move to pairing and trunk-based development as trust and automation mature.-
  • FizzyOrange@programming.dev
    5·
    11 days ago

    I can’t get the person in charge of the repo to let us run the CI automatically on PR

    Ouch. Time for a new job. (I’m not even joking - I’d quit if it was that bad.)

    • TehPers@beehaw.orgEnglish
      5·
      10 days ago

      In this case, it’s a customer’s environment, so it’s actually not one of my direct coworkers that’s blocking this. Otherwise I’d agree.