Archive for November, 2007

November 1st, 2007

Book Reviewlet: Best Kept Secrets of Peer Code Review

by Tim Cull

Jason Cohen has obviously spent a lot of time thinking about code review and his book, Best Kept Secrets of Peer Code Review, shows it. Partly marketing brochure, partly master’s thesis, and partly just a normal software book, the text does a better job than some other software books citing references and backing up opinions with facts and figures.

My interest in it ebbed and flowed; the beginning spends a lot of time talking about why Cohen thinks code review is a good thing but wasn’t terribly interesting. The middle of the book, though, was the meat I was looking for. It goes over different styles of code review and in particular compares and contrasts a more formal, meeting-intensive and laborious style with more lightweight, distributed and online style. Turns out, lightweight can be almost as good as heavyweight at finding defects; and when you factor in the cost of finding those defects then lightweight wins hands down.

The last part of the book is skim material that mostly talks about the code review software that Cohen’s company sells.

Some good tidbits I took away:
1) After about 60 minutes of looking at a pile of code, your performance finding defects in it trails off. This effect is the same no matter if the code is 20 lines or 20,000.
2) The optimum review rate is 250 – 400 lines of code per hour
3) #1 and #2 imply that the average code review should be around 400 lines of code.
4) Most defects are found when a single person sits down alone to look at code in concentration. Contrary to popular belief, the fewest are found by a group of people looking at code together and talking to each other while they’re doing it.
5) Even if all you ever do is make yourself review your own code after you’ve written it, you will find a decent number of defects.

One of the developers on my team recommended this book after we created a “stewardship” role on the team. Basically, the application had become too big for me to review all changes myself, so instead I gave the more senior guys on the team a particular area to be stewards for and they review code changed there. This kind of arrangement, incidentally, seems to have worked out well if you want to try it.