&gt; What often goes unmentioned in praise for code review processes is their insanely exorbitant costs -- measured in engineer hours but perhaps more costly is all of the blocking and impedance [1]. Most of the &quot;problems&quot; that code reviews claim to address can be solved by much more direct and optimal measures. Code reviews are damn expensive.<p>I&#x27;m on a team where for about a year, part of our process has been that code doesn&#x27;t get merged until three people say it&#x27;s ready. If one person wrote it, it needs two reviews, or if a pair wrote it, it needs one review.<p>Your mileage may vary, but my experience with this is that the code reviews increase latency, but don&#x27;t really have much effect on bandwidth. It might mean that there&#x27;s a few hours between finishing your code and merging it into master, but during those hours you can be doing other things. Most code reviews take &lt;10 minutes, and I usually just check for other people&#x27;s PRs when right after I create a PR of my own, so it doesn&#x27;t interrupt my flow.<p>Sometimes PRs do get blocked, but in those cases it&#x27;s usually for good reasons; the design has some serious flaw or is very overcomplicated, or there&#x27;s a bug. I see that as similar to a failing build. Sure, a CI server sometimes blocks you from merging, but do you really want something that fails tests or doesn&#x27;t compile going into your master branch anyway? Code review is just like having a CI server that builds and runs tests, but it checks things that can&#x27;t be automated.<p>We do sometimes run into cases where code review takes a long time, but the root cause there is usually that we didn&#x27;t break down the feature into an adequately small enough minimum viable product. 1000 lines of changes takes more than 10 times as long to review as 100 lines of changes; the increase isn&#x27;t linear. If code review is taking a long time, it may be an indication that your continuous integration isn&#x27;t continuous enough.<p>That said, &quot;code review is 100% necessary&quot; and &quot;code review is 100% too costly&quot; are just different kinds of Kool-Aid you shouldn&#x27;t drink. &quot;People and interactions over processes and tools&quot;[1] applies here. What works for my team might not work for yours. I&#x27;m not arguing for code review; there&#x27;s no universal right way to create software. I&#x27;m arguing that code review is an effective process step for some teams and an ineffective one for others.<p>[1] <a href="http:&#x2F;&#x2F;www.agilemanifesto.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.agilemanifesto.org&#x2F;</a>