The practice of code review is a lot like going to the gym: You know it’s good for you, but you don’t always do it.
A study by Forrester Research released at the end of March found that code review processes are often ad hoc in nature and have not kept pace with the increasing complexity of software development. Further, the study found that organizations do not make the time to institute code review as a formal part of the development process.
Gwyn Fisher, CTO at code analysis software company Klocwork, which sponsored the Forrester study, cited a number of factors working against formalized code review. “It’s hard to motivate people to do something that’s not pleasant,” he said. “It’s potentially devastating for the person whose code is being reviewed, and it’s annoying for an architect to get pulled away from his tasks to participate in a review. Even getting people to buy into a process that may or may not find something is hard to do.”
The benefits of code review are well understood; finding bugs earlier in the life cycle was the top reason given by 84% of the 159 IT professionals surveyed who are directly involved in their organizations’ development and code review processes. Other benefits included the sharing of best practices and highlighting new techniques, as well as the encouragement of refactoring and code simplification.
But the survey respondents said the biggest challenge they face is finding enough time to prepare for a review. Part of the reason is that in development, it’s hard to predict when code will be ready to review, the study found.
“What we see is that there will always be hesitancy to believe in the idea that if you invest time now, you can save it later,” said Gregg Sporar of code review software provider Smart Bear Software, now a division of testing company AutomatedQA. “People say they won’t get any real value, that code review is too cursory and you won’t find the really interesting stuff. Our response to them is, ‘Maybe you’re not doing it right.’ ”
Forrester recommended that code review should be made a formal part of the development process. If the organization is doing agile development, code review should occur as part of the “done” criteria for a story, the report said.
In waterfall development, a build should not be considered finished until code is reviewed. “By making code reviews a milestone, it’s possible to report on the status of the milestone. This helps ensure that code review, although a very technical activity, has the same level of visibility of other activities in the process,” the report stated.