Code reviews: what are they good for?

Pick an urban park with paved paths, and beside it you'll see the path people actually take. Worn in the grass. It's called the desire path. First instincts suggest that the planners got it wrong. The worn path is the true path. But is that true?

A desire path is the path of least resistance for the people who created it. It's a shortcut for able-bodied people. But it's not the path for someone in a wheelchair or pushing a pram through mud. They need a paved route. Both paths add value.

Chesterton's fence reminds us to think about why things exist before we go to replace them.

G.K. Chesterton wrote way back in 1912:

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

Code Reviews

This feels like an important reminder in a time when we're eagerly codifying all our engineering processes into agents. The one that's getting plenty of attention now is code reviews.

The concept of the code review was introduced at IBM in 1976 to catch bugs. Michael Fagan's formal inspection was built to find defects early, when they're cheapest to fix. Today's pull request is a lighter, looser descendant of that. The data show that very few bugs are caught this way. Across studies that classified what review actually changes, roughly three-quarters of the issues are about maintainability and style, not whether the code works. The bugs it catches are mostly the small kind tests already catch.

Code reviews come into play for knowledge sharing and to provide a formal method of approval. Microsoft's own study of the practice found that reviews are less about defects than people expect, and more about knowledge transfer and team awareness. My experience is that peer reviews are there as part performance theatre, part sharing knowledge and part coaching of junior engineers. Where you work plays a part here. I've worked inside XP teams using pair programming as their method of review. I've also worked in highly regulated environments where pull requests are a form of compliance. The work a code review actually does is decided by the value placed on it.

What is the work?

This matters because if you or someone in your company is thinking of replacing peer reviews with an agent, it's worth understanding what might get lost if the intended intent, rather than the actual work, is the one that's automated.

If peer reviews are doing other hidden work beyond 'quality gate', you're going to need to pull that apart, find out what the actual work is and ways to replace that work.

For instance, if the real value of a quality gate is accountability, how will the agent provide it? If it's to coach junior software engineers, will that still be required and what other programs need to be put in place? If it truly is to quality gate, are linters a better option?

And if peer reviews are simply performance theatre, are they needed at all? What does accountability look like when agents build, test and deploy? What sort of coaching will juniors need if code is no longer the currency?

These are the interesting questions we can be asking ourselves. Before we jump to paving the path around the fence, let's ask what that fence's intent was, what it's really for now, and whether it's doing the work we think it is — or other, hidden work. The kind we only discover once it's gone.