Everyone admits that doing a code review is expensive. It takes time, particularly when everyone is in a mad rush to get the software project finished and thrown over to the software testing department. It requires that people who aren't involved in a particular chunk of code drop what they're doing to pay attention to someone else's needs — Oh no, not another meeting?! And for some developers, it just seems like an opportunity for more office politics and backbiting.

A code review might generate an incremental improvement in the code, say those who are ready to "postpone" the code review meeting. But gosh, we're too busy for that. And what we have is good enough.

Oh yeah? If you think that all you'll get from running effective code reviews is slightly better software, you need to think again. Here's five not-so-obvious reasons for code reviews—and inspiration to put to work the advice in the other articles in this Running an Effective Code Review series.

1. Developers know their code will be evaluated, so they work harder.

"The most useful thing about a code review is the fact that the coder knows that someone is going to review the code," says Oliver Cole, president of OC Systems and also lead for the open-source Eclipse Test and Performance Tools Platform project.

It is rather like the final exam for a Calculus 400 class, Cole says. It doesn't matter if you take the exam, he points out. The exam adds no calculus learning, when the whole point of the class is to learn calculus. "The purpose of the exam is to make you study," he says.

The same thing applies to code reviews, explains Cole, perhaps even more so. "Computer programmers have large egos with respect to the code they produce," he points out, and caffeine-sodden programmers work late into the night because they are really into their work rather than motivated by money or other concerns. So a code review appeals directly to a developer's sense of personal pride.

"The biggest benefit of code reviews is that the coder really does not want any criticism of his code," says Cole. Knowing that the code will be examined by others encourages a developer to take the extra effort to do a good job. "The actual code review usually does not show up much (with experienced programmers). But much better code gets produced if the coder knows someone is going to criticize it," he adds.

Cole gets full agreement from Alex Russell, the mastermind behind the open-source Ajax Dojo toolkit, who is now at Google working on the Chrome Web browser. Code reviews have to be expected, he says. "Everyone needs to know that someone else will be reading their code and have realistic expectations about what that means," Russell says.

Aside: If it hasn't occurred to you that this "others will see my code!" point is a major reason behind the success of open-source code quality, you aren't thinking it through.

2. It improves a developer's own programming skills.

In your heart, you might not care that much about the success of this particular software project. But most programmers want to improve their personal skills, and that means learning from other people. There's no better opportunity for such enlightened self-interest than a code review.

For example, input from a good developer can make you more aware of what the programming language can do, says J Schwan, managing partner of Solstice Consulting, a Chicago-based technology management consulting firm. You'll learn to write more efficient code, and find out about other patterns available for organizing code.

Christopher Buchino, director of software engineering at GotVMail Communications also believes code reviews help the group to collectively learn from one another's mistakes and to become better programmers. Through straightforward feedback, he says, the company raises the bar set for its developers. "They appreciate it because they know it will make them better," he says. "When code is reviewed by the group, the team learns and grows, but what is even better is that the code becomes of higher quality and is easier to maintain."