Have you ever noticed how hard it is to get people to do code reviews? It seems like developers and project managers alike are allergic to them. I’ve noticed that when I talk to people about code reviews, the same few objections come up over and over again. I think it’s worth looking at those objections, and why they don’t really make sense when you think about them.

Myth: Code reviews are a waste of programmers’ time.

For some reason, many programmers and project managers will shoot down code reviews, claiming that they’re a waste of time. In my mind, if a practice is a waste of time, it means that practice doesn’t save the project more time than it it costs to perform. And in my experience, this just isn’t true when it comes to code reviews. When I hold code reviews, I often find that the team ends up with a sense of relief because we caught a bug which would have been far more work to track down later on.

Typically, a code review with four people will requie about ten person-hours: each person spends about half an hour preparing, and the meeting lasts about two hours. In that time, we almost always identify a couple of defects which we probably wouldn’t have found otherwise. Everyone is keenly aware that had those defects been caught by the testers (or, even worse, the users), it would have taken a lot more than ten hours to track them down. It’s not uncommon for a code review to start out with a bunch of groans, only to end up with all smiles!

Of course, “data” isn’t the plural of “anecdote”. However, my individual experiences are borne out by many studies, which have found time and time again that code reviews (and, in fact, most accepted inspection practices) pay for themselves.

Myth: Code reviews aren’t effective because you can’t review all the code.

It’s true that code reviews cannot cover all — or even most — of the codebase for all but the smallest applications. Since code reviews can only catch defects in the code samples being reviewed, doesn’t this mean that they’ll only catch a tiny fraction of the defects?

But just because you can’t review all of the code in the project, that doesn’t mean code reviews aren’t worth doing! It turns out that if the right code samples are selected for review, then code reviews can be very effective. In most projects, a large number of defects tend to be concentrated in relatively small pockets of code. If the code is selected well, then the review will catch the most costly defects.

Note: You can use this code review checklist to help select the right code sample.

Myth: Given a chance, programmers will endlessly “tinker” with the code.

This seems to be one of those ideas that only managers come up with. I’ve never met any experienced programmer who would think of using a code review to “tinker” with code. It turns out that a code review is a pretty poor forum for some sort of mindless code “beautification”. Reviewers are not engaging in a top-down redesign of the code — they only bring up problems which they believe are defects. What’s more, the collaborative aspect of the code review meeting tends to discourage any changes that are only made for the sake of making changes. (It turns out that software developers are a pretty pragmatic bunch, and they have a low tolerance for useless behavior.)

Still, it’s good for the meeting moderator to be aware of this myth. That way, he can cut short any discussion which he thinks is leading down that path.
Myth: Programmers aren’t paid to sit around and talk, they’re paid to code.

There’s a great story in Peopleware by Tom DeMarco and Timothy Lister (which is a fantastic book that everyone involved in project mangaement should read). A programmer is sitting at his desk with his feet propped up, staring into space. His manager comes by and demands to know what he’s doing. The programmer says that he’s thinking. The boss asks, “Can’t you do that at home?”

Software development — in fact, any engineering activity — requires a lot of thought, and a lot of discussion. It’s rare for programmers to be given the time that they need to discuss the difficult problems that they routinely encounter. A code review is a great opportunity for a project manager to encourage that sort of discussion.