It’s Time for Your Review
April 15, 2007 —
(Page 2 of 3)
One of them, Jason Cohen, founded a company called Smart Bear Software thatas you would expectmakes and sells a tool for peer code review. He took some time from distributing a book he wrote with his colleagues called Best Kept Secrets of Peer Code Review to talk about its benefits with me, regardless of tool.
Peer code review, he stated flatly, reduces the number of errors that get into code, and so is a savings all the way down the development line. In his book, he cites an example in which peer code review saves a company half of the cost of fixing the defects, and adds that 162 additional errors were found during the review.
Cohen asserts that one of the things holding back greater adoption of peer code review is that the formal processes laid out in works by such notables as Michael Fagan and Karl Wiegers involve seven-phase meetings with assigned roles to prevent defects from getting into code. The whole process of defect detection and correction simply takes too long when done in this way to be practical to many organizations, Cohen notes in his book. He acknowledges the meetings are successful in detecting defects, but says most organizations cant afford to tie up their sharpest developers in lengthy meetings.
Formal review meetings also dont align themselves well with iterative or agile development processes, Cohen said. A formal meeting of four people for two hours, which is a proper Fagan inspection
thats a day in terms of man-hours, he said.
At the other end of the spectrum, theres the over-the-shoulder, Hey Bob, can you take a quick look at this? technique. Any review is better than no review, Cohen said. The shortcomings of this method, though, are clear. Youre just not getting a lot of coverage, its not enforceable, and there are no metrics.
Other methods include what Cohen calls the e-mail pass-around process, which is difficult to follow when you start talking about errors in line 31, but line 31 is now line 17 because changes have been made to the code; and pair programming, as advocated in agile processes.