Code Reviews
Traditional approaches put a lot of emphasis on Code Inspection or Reviews to find defects. In human terms, that is like an editing process. The problem with code inspection is that, even under the best circumstances, it finds very few defects, and the ones that it does find are shallow. The challenge is that our brains are not designed to read hundreds of lines of code in a single sitting. When we do this activity, we tend to notice small improvement opportunities (e.g. a method or variable is poorly named) and might spot a way of simplifying a few lines of code. But we fail to ask bigger questions about the design, flow, etc. Static analysis tools better spot most things that a human code review finds.
To make matters worse, code reviews and their close friend, pull requests, add delays to a system. Delays increase our cycle time, without adding value.
W. Edwards Deming had a good quote for this:
Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
Consider Pair Programming or, even better, Ensemble Programming instead.
Resource Links
- The case against code reviews - Jo Crossick
- Code review vs. Pair programming
- Evolving Code Reviews Into Pair Programming
- Pair Programming > Code Reviews - Theodore Nguyen-Cao
- Software Code Reviews from a Deming Perspective - Build Quality. Inspection is for learning not quality (Source of my Demming quote)