Editorial note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. While you’re there, have a look at their automated analysis and documentation tooling.
Before I talk in detail about trying to automate code review, do a mental exercise. Close your eyes and picture the epitome of a soul-crushing code review.
You probably sit in a stuffy conference room with several other people. With your IDE open and laptop plugged into the projector via VGA cable, you begin. Or, rather, they begin. After all, your shop does code review more like thesis defense than collaboration. So the other participants commence grilling you about your code as if it oozed your incompetence from every line.
This likely goes on for hours. No nit remains unpicked, however trivial. You’ve even taken to keeping a spreadsheet full of things to check ahead of code reviews so as not to make the same mistake twice. That spreadsheet now has hundreds of lines. And some of those lines directly contradict one another.
When the criticism-a-thon ends, you feel tired, depressed, and hungry. But, looking on the bright side, you realize that this is the furthest you’ll ever be from the next code review.
It probably sounds like I speak from experience because I do. I’ve seen this play out in software development shops and even written a blog post about it in the past. But let’s look past the depressing human element of this and understand how it proves bad for business.