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.
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:
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?
The reviewer realizes the code is fundamentally flawed and approves it anyway.
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).
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:
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.
If you enjoyed this post, you may also enjoy: Balancing The Desire To Under-Engineer and Over-Engineer