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.”
3. It’s an opportunity for mentoring, so the programmers you work with get smarter (and thus, more fun to hang around with).
This is the reason you were expecting to read: Code review helps teams train new developers and familiarize peers with other modules. And certainly, that’s so. “The review process helps foster the sharing of ideas and making the code reusable,” explains Paddy Sreenivasan, the co-founder and vice president of engineering for Zmanda, an open-source backup and recovery software provider.
Yury Uskov, director of business development at CPS Labs describes code reviews as a systematic way for team leads to share their experiences with every engineer. “When the lead rewrites some procedure, making it 50 times more efficient in three minutes, it is exciting!” Uskov says. “Working with another’s code, you can find something new or invent a new solution for some task.”
But although mentoring is the usual benefit cited (for good reason, mind you), a code review isn’t always the best time for mentoring advice. Christopher Phillips, director of software engineering at IAC Consumer Applications & Portals, says, “While the intention [to mentor individuals] is generally well meaning, it can often lead to individual discomfort and perceived or actual criticism. In these cases, the greatest opportunity for mentoring usually exists in the context of small collaborative teams working together to realize goals and not in a code review.”
4. It creates consistency and a culture of quality across the project.
“Code reviews with the goal of ‘best practices’ in mind offer tremendous opportunity,” says Phillips. Code reviews give both the code base and the team an opportunity to develop a sense of consistency and reliability, leveraging the experience and expertise of the team as a whole, he says. “Individual coders are honing their professional skills and experience while contributing their experience and expertise to the company and the team,” he adds. That gives the company a tangible return on their investment: happy developers, and also working code with continually increasing competency and consistency. What’s not to like? (For more on creating team standards in code reviews, see Running an Effective Code Review.)
Code reviews help create a subtle change in what is measured and therefore managed-and doing a code review well can make a huge difference in improving software quality. Developers are quick to complain about being judged on the wrong metrics, but, says Gary Heusner, client partner at custom software developer Geneca, “We have to change the rules to allow for quality and efficient development to be valued over making milestones that are really yardsticks of process more than milestone of value delivered.” Code reviews are a big part of that.
5. It encourages team bonding.
“People think code review is just about finding bugs, but it brings people together, says Smartbear’s Jason Cohen. Often, he says, it can deliver far more than expected.
“Success stories happen very often when performing code reviews,” says Dave Katauskas, senior architect at Geneca. “But the best success story is the pattern that develops once a team has gelled. The longer you’re into a project, the better quality code is created. This is all due to the code review process and governance that occurred up stream in the beginning of the project.”
Now that you’re (re-)inspired, let’s take a look at some of the components of an effective code review. That’s next up in the series: