Knowledge distribution · Observability
A review with no discussion is not a review
The proportion of changes approved with no comments at all, and the proportion approved by their own author, predict post-release defects after controlling for size, complexity and churn — which review coverage by itself does not reliably do.
Do this firstA second person has actually done the risky task
The measurable thing about review is whether it happened. The thing that predicts defects is whether anything was said.
This is a control about what you count. An organisation that tracks review coverage will reach high coverage and may get nothing for it, because a rubber-stamp approval is indistinguishable from a real one in that metric and distinguishable in the defect data. Silent approvals and self-approvals are both cheap to detect and both worth looking at.
Be careful about the obvious perversion: mandating a comment count produces comments. The signal is a reviewer who engaged, and no metric captures that directly — which is an argument for watching the number rather than gating on it.
The decoy
A review coverage target. Getting every change reviewed is measurable, reportable, and — on its own — was not enough: components with high coverage were still defect-prone, and coverage explained defects in only two of four releases studied.
Evidence
- The Impact of Code Review Coverage and Code Review Participation on Software Quality — II"Low code review coverage and participation are estimated to produce components with up to two and five additional post-release defects respectively." Changes approved with zero comments were significantly associated with defects across all three releases studied, as were self-approved and hastily reviewed changes.
Last reviewed 2026-08-19.