STOP doing Code Reviews

Someone has to say it, might as well be me: STOP DOING CODE REVIEWS! You are probably wasting your time.

OK, this is a bit tong-in-cheek so resist the horror and read on please.

In an open source world, you meet passionate developers who spend their free time contributing to the ecosystem of open source code, a responsibly raised and healthier alternative to its corporate counterpart.

A few opinionated, and strong headed gatekeepers keep the purity of their baby by carefully reviewing any code that someone wishes (dares!) to merged into the main branch, and reject the slightest impurity with dogmatic fervor.

This DOES result in good code.

Problem starts, when corporations, in feverish thirst for more efficient IT, adopt this and other open-source practices as the Holy Grail.

Code reviews, when done properly, can yield great results, but hardly anyone does them right. I do not do code reviews poorly and refuse to ‘approve’ any pull request otherwise. I’ve solidified in this conviction not so long ago, when faced with approval request for a pull request with dozens of commits, dozens of files, for a program I never heard of. I decided then and there, that I WILL NOT put my name next to the “approved” stamp for such a thing, because I do not lie.

OK, ok, I’ve lied a bit in the past, but what can one do when colleagues subject you to viewing 100 pictures of their “beautiful, adorable infant"?

Code reviews, give you that warm feeling, but as someone once told me on a project back in the 20th century that “so does pissing your pants”. Worse, done poorly, they are a waste of your time, and give you a misleading feeling of security.

But you will not stop doing code reviews…. you can’t. That is just not politically correct…?

So if you must, please, do them right! For this, one must count to 3 or was it 4?

1.??????Allot proper amount of time for the code review. Actually have a task, or allow certain number of hours per week to do code reviews and do them well.?

2.??????Provide a check list of things to look for in a code review. It should be a short one pager, that your team will focus on temporarily or permanently

3.??????Allot proper amount of time for code improvements following the code review. Do not only fix bugs, but actually have it in your plan to spend some time to adjust your code based on feedback from the reviewer

4.??????Have a list of reviewer per application – those should be people that know and care about the application. Do not just ask a random developer who happens to know the language.

You have to give your developers a message that they should spent significant time doing a good review. They must also know what to look for; developers are not compilers and will not catch all bugs, but a short one pager check list of what to look, will allow them to focus on what you feel is important. The check list should come from your coding standards and can and should change over time. This also brings an objective standard and compelling reason to apply code review suggestions, for which you should explicitly allot time for. Whenever possible, assign reviewers to applications?who are familiar with it, and mostly importantly, but most elusive care for its quality, like Sir Galahad, the chaste.

There is A LOT more than can be said about this, a topic for a book, which this is not. However, starting with those, will take you a long way.

Better yet, forget pull request reviews and do “software inspections” a method I advocated for long ago. It is hard to apply because it is time consuming but it works when applied.

For more on this topic, please take a look at a similar article I’ve written at the turn of the century.?