A team's code review process is slow and catches few real problems. What should change?
Show the full answer Hide the answer
What should change, in order
1. Reduce change size. Review effectiveness falls sharply with size — beyond a few hundred lines, reviewers skim, and beyond that they approve. A large change gets fewer comments than a small one, which is a signal about attention rather than about quality. Small changes reviewed thoroughly beat large ones reviewed nominally.
2. Automate everything mechanical. Formatting, linting, dependency direction, test coverage, security patterns, forbidden imports. A human commenting on formatting is a waste of the scarcest resource in the process, and it crowds out the comments that matter.
3. Be explicit about what review is for. Correctness of the approach, missed cases, unintended consequences, readability for the next person, and knowledge transfer. Not style, which is automation's job, and not architecture, which should have been agreed before the code was written — a review that raises an architectural objection has discovered it in the most expensive possible place.
4. Set a response-time expectation. Review latency is frequently the largest component of cycle time, and it is invisible in most metrics. A day of waiting for review costs more than the review saves.
What review is bad at
- Finding subtle concurrency bugs, which need tests and reasoning rather than reading.
- Catching performance regressions, which need measurement — no reviewer holds a latency budget across a diff.
- Assessing architectural fit, which is too late by the time code exists.
Those need different controls: fitness functions in the pipeline, automated performance checks, and design discussion before implementation.
The cultural variable
Whether reviewers are rewarded for finding problems or for approving quickly. Both extremes are damaging — one produces bottlenecks and adversarial review, the other produces rubber-stamping. The healthy version treats review as collaborative and measures the process on cycle time and defect escape rate together, not on either alone.