Code Reviews: A Multi-Tool You Paid Too Much For and Now Hesitate to Throw Away

The other day I saw someone's post in the feed starting with “Code reviews. Is it just a waste of your time?” and thought, “Of course not! I’m paid hourly. It’s a waste of company money!”

Ten years ago, I was enthusiastic about everything V&V. I was working in nuclear power plant automation, and my interest at that point was around static code analysis. Of course, given all the shortcomings of automated code analysis, making people do the same thing by hand sounded beautiful!

Besides, code reviews are not only about analysis per se. We all know that it’s a three-headed beast. First, it’s the review itself. People are supposed to find defects computers themselves can not. Second, it’s a knowledge transfer tool, you give and take feedback, and it should teach you a thing or two. And last but not least, it’s a social something-something. It is supposed to enhance the feeling of collective responsibility somehow.

As the three-headed Cerberus, code reviews are supposed to keep you from entering hell, and as the three-headed Cerberus, it only works in ancient myths. As with every multi-tool, code reviews suck at all its purposes.

Code review is simply the wrong time and place to make people look for defects. Code-level defects are either easily detectable by tests, compilers, and static analyzers or... insignificant. You want another pair of eyes way before the code has even started to appear. You want people to discuss ideas behind your code, not the most fashionable way to convert an integer into another slightly larger integer. You want people to protect you from the mistake of writing the wrong thing in the first place. People are very efficient at finding large-scale issues. Looking through hundreds of lines of code searching for the code smells compilers don’t even care about – not so much.

As a knowledge transfer tool, it’s about as effective as the last night before the exams. Nobody is eager to learn things at the last moment, you already have your eyes on the prize, and every new comment is more the source of frustration rather than insight. That’s why nobody is eager to teach at the last moment either. If you see that there is a lack of knowledge transfer in your team, the best you can do is to embrace and encourage one-to-one conversations before and not after the code is done. Time-tracking undermines that kind of activity, by the way, but that’s a topic for quite another rant.

And regarding social something-something, it’s hard to dispute the efficiency of code reviews because social something-something is simply impossible to measure. In my experience, code reviews may help consolidate the team if and only if everyone on the team adheres to the same level of toxicity. Otherwise, it only creates grudges and disincentivizes people from introducing any large and potentially explosive changes.

In my opinion, which you are certainly entitled to challenge, code reviews are a thing of fashion. Organizations are doing it because the big boys are doing it. Well, in the early 2000s, when KPI and SMART were the fashion, people were getting bonuses depending on how many lines of code they wrote. It took quite a few years to realize that this was not such a good idea.

As Fred Brooks wrote in his famous “No Silver Bullshit—Essence and Accident in Software Engineering": “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.” Well, he also argued that high-level languages might have been one, but that was in 1986. Now, three decades later, when nothing works properly except a very few things written in assembly, I’m starting to believe that the silverness of high-level languages has also been overstated.

But that’s also a topic for quite another rant.