Code reviews are seen as an essential part of software development. It makes a lot of sense to say that a programmer should have their work reviewed by another programmer. Authors and journalists have their work reviewed by an editor after all. Humans make mistakes and creators especially get a little tunnel vision when they are focused on making their creations. Having someone else look at it can catch many errors.


In software development, code reviews also have the added benefit of reducing your reliance on a single person. With code reviews, multiple people have looked at a piece of code. If the original author disappears for any reason (gets sick, quits the company, is hit by a truck, etc), someone else is familiar with that code in case any issues arise.

The theory behind code reviews is sound. The problem is what happens in reality. Reading software code is not like reading a novel. Whereas novels are linear:
software is a branching system:

If the amount of code being reviewed is small, then it is more likely to be linear and easier to review:

Unfortunately that often applies to bug fixes or small tweaks to features. Major features are rather large. A developer I know told me that he and his teammate would often do week long code reviews. Not great for the developer waiting on a review and not great for the developer doing the review. Definitely not great for the company that needs software delivered to users.

Another major problem with code reviews of this size is that a review of code is happening after days or weeks of development have gone into it. What happens if the code is fundamentally broken and needs to be rewritten from scratch?


One possibility is that the code review discussion results in rewriting the code. This is highly unfortunate because a lot of time was wasted on writing the original code. Losing days or weeks of a developer’s time with little to show for it is not a recipe for a successful business. I personally have not seen this happen very often though. What does happen is much worse.

The reviewer realizes the code is fundamentally flawed and approves it anyway.


This happens when a deadline is approaching and the team can not afford to rewrite days or weeks worth of code. So they accept the broken code and any issues that may happen down the line such as bugs or the website going down when a lot of people go to the site. The project is delivered “on time”, but with obvious adverse effects. More time is spent cleaning it up in the following months than would have been spent rewriting it.

The common response to these problems is that all code reviews should be broken up into small chunks which make it easy to review. It makes sense because the smaller the amount of code being reviewed, the more linear it becomes. However, that argument ignores the value of context. Imagine someone creating a very well written introduction to Quantum Physics. You may read it and go “Yep, that’s a well written introduction! I feel like I understand the general idea of what Quantum Physics is.” Yet it would be completely inappropriate if that well written introduction was put in the middle of… a romance novel (unless you have a very niche demographic for that romance novel).


An alternative to code reviews is design reviews. This is a high level discussion of how an entire system is supposed to work before any code is written. It is way easier to have a discussion around a diagram:


Than it is to have a discussion around code:


I love design reviews because you catch problems early and you have more meaningful and important conversations around the code being written. Going back to the novel analogy: it is more important to discuss the high level ideas such as general setting, character development, major plot twists, etc, than it is to make sure that individual words and sentences are perfect. Being grammatically correct with correctly spelled words will not help if the novel as a whole makes no sense. The same is true of software.

The problem with design reviews though is that they can be overkill. They make sense when you have to build something from scratch. They make less sense with most software bugs. With bugs, you don’t necessarily know where the problem is or how to fix it right away. It is a lot of investigation with a lot of trial and error. By the time the root cause is discovered, the programmer may already have a fix for the bug. This is when code reviews make sense. Why do a design review when the code is already written? Do you review the setting of a novel after fixing a single typo? Probably not.

Code reviews and design reviews are like any other tool in a programmer’s toolbelt. Sometimes one is appropriate and sometimes the other. It should be up to the team to decide which they need to use in a given situation. The idea that every team should always do one or both for every piece of code that is written is the equivalent of having a hammer and seeing nothing but nails.