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.-
  • ISO@lemmy.zip
    15·
    16 days ago

    How many layers should I go through?

    Here is a few:

    • PR’s replaced patch sets. Patch sets have nothing to do with “strangers”. Both are the medium where review for a logical grouping of code changes takes place. There is no separate categories here.
    • In most open-source projects, everyone involved is a “stranger” to others anyway, including co-developers if any.
    • PR’s/patchsets are orthogonal to T*D/Trunk-Based/Team-focused development. How can this be missed is hard to imagine. I would have assumed everyone is aware of draft/wip/rfc PR’s, or dev/trunk branches. And tests need development alongside functional modifications anyway.