Code reviews aren’t just for catching bugs
While I value many of the same things as the author, I&#x27;ve found code reviews to be far inferior in every respect to pairing (especially promiscuous pairing (google it)), and to have negative effects in several important ways:<p><pre><code>  * They delay integration.
  * They tend to encourage focus on abstract code polishing without proportionality or relation to the value of the code.
  * They favor superficial improvements, while increasing the costs sunk into paths that may be deeply flawed. (They facilitate late code-structural feedback, but not early directional&#x2F;problem-analytical feedback.)
  * They often discourage more collaborative work and therefore quicker and richer feedback, by their presence as a substitute for pairing.
  * They create impediments to work moving quickly to completion.
</code></pre>
Of these, the most egregious is the distraction from value. Teams that are spending a lot of time and energy talking about code quality (which is absolutely important, but not primary...the best teams I&#x27;ve seen maintain a high level of quality and talk about tradeoffs involved in delivering value at high quality) are often neglecting communication about where value lies and how to deliver it most efficiently.<p>[edited for formatting]