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.-
  • screaming in digital@lemmy.mlEnglish
    6·
    15 days ago

    not a professional programmer, by any means - but PR’s (for me) slow development down to a point where code matches the philosophical/algorithmical goal. when code development is at the proper pace, it dramatically reduces the need for refactoring.

    edit: upvoing this post, because the comments are particularly interesting - as with any “good” post :-)