In a lot of software shops there’s a general opinion that formal “code reviews” are a good practice. This is something that has become more mainstream in software development over the last decade, popularized in part by big companies such as Google who have used it as part of their formal internal software development processes.
I’ve done code reviews at several jobs over the years, and it’s never been a positive experience. There are fundamental problems with code reviews as a formal part of development, but at a basic level code reviews are not a good use of resources. The time and energy spent by developers doing code reviews is time better spent on other development work.
The Human Element
People, as in most elements of life, are the biggest problem with code reviews. Developers are hired to program machines to perform automated tasks using logic and mathematics. Although most are great people they aren’t renown for deft social skills. Many many times I’ve seen both the authors and reviewers of code walk away with hurt feelings and the team’s morale and effectiveness permanently damaged.
Any company that is serious about code reviews no doubt has a set of “guidelines” for effective reviews, and one of these is usually “don’t hurt anybody’s feelings”. That sort of glib instruction is generally not effective.
The bottom line is this. People are assholes. Software engineers are no exception. Unless you are blessed with saintly developers who all have tight personal bonds and no fear of judgement, think twice about subjecting them to reviews.
The Money Element
This one is really obvious, but it seems almost taboo to talk about it. When you perform regular or mandatory code reviews you are spending far more money on a feature or change than the money already spent developing and testing it. You’re spending money both on the submitter and reviewer(s) time to do the code review, as well as the lost opportunity-cost of what those engineers could be doing instead. Worse still is if the reviewer(s) of the code request changes or even wholesale rewrites. Now what could be a simple bug-fix or enhancement has become exponentially more expensive.
The money and time spent on code reviews could be more effectively spent on developing automated acceptance or integration tests for the code, or even simply educating and socializing the code informally.
What Should You Do?
The common use of code reviews is really a missed opportunity to improve both your software and y0ur team dynamics. So here are my recommendations for better engineering practices in lieu of code reviews:
Pairing
Pairing is the best and most expedient way to ensure that one person doesn't have all the knowledge of a feature or piece of code. If you really want the benefit of code reviews this is the one best way to get them and boost team cohesiveness and effectiveness at the same time. Ideally development pairs should change relatively often, so that team members can build better interpersonal relationships as well as get exposure to all parts of a software system.
Shared Values
Discussing or worse arguing about the merits or deficiencies of code in a review is time better spent talking about the code before its written. A shared, agreed, socialized set of standards for code, such as test coverage expectations, etc. is a better way to ensure quality code up front. Teams that use agile development processes should ensure that stories have very clear definitions of what constitutes quality in the produced code.
Acceptance Tests / Automated Tools
Automated acceptance tests, preferably written by someone other than the feature developers, are a great way to ensure the written code is bug-free and meets the requirements, and is much more objective than human-led reviews.
Automated code review tools can be used if the team wants to ensure a consistent style in the codebase and to ensure some preset level of test coverage, although these tools often lead to testing theater.
Do You Work for Google?
In ideal circumstances, with a tightly knit team of engineers who have good personal relationships and great people skills, as well as a product manager with an abundance of time and money, code reviews can make sense. I have never personally worked in such an organization, but if you do please hire me.
If your organization doesn’t quite meet up to the above statement, leave code reviews to the software gods and focus on building quality into your software from the start.
