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.

GenAI makes the underlying problem harder, not easier. When we write code ourselves, we build a model of the problem first and the code second. Reviewing generated code means constructing that model at the same time as reading the code for the first time, in diffs that are routinely a thousand lines long. That is a different and more demanding skill than the one this entry describes, and it is one we lose if we stop practicing it. See Skill Loss and GenAI: Make It a Choice, Not an Accident.

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.