Best Kept Secrets of Peer Code Review
Long ago, back when green screens and green-bar paper roamed across the software
development landscape, I was a young software developer at a startup software company.
There was a development group that I worked with that held periodic
code reviews. These were conducted as lengthy meetings with the entire team
gathered around a conference room table. Everyone had a printout of the
code (written in COBOL), and they
were expected to have studied it closely before the meeting.
The team member whose code was being reviewed would
lead the meeting. I sat in on one of those meetings and it appeared to me that
the return on investment (ROI) was pretty low. The leader of the meeting would say things
such as, "And on line 147 I'm initializing the control break variable." The collective
response was usually silence.
I suppose they occasionally found bugs using this approach, but it sure seemed like an expensive, heavyweight process. Years
later I worked in an environment where we used a much lighter weight code review technique.
It was a casual process where at any moment the developer who wanted to commit code would wander down
the hall and find someone to do a review. The developer would explain the code changes and
the reviewer would watch as the developer stepped through the code displaying the differences
between the current version and the proposed changes. The cost of this lightweight approach was much
lower, but I was always bothered by two things: the developer had complete control
over the process and the reviewer had no prior access to the changes.
Two different environments with very different approaches to doing code reviews. The one thing they had in common was that there was never any attempt made to calculate the return on investment. I suspect it was low in both cases. Low ROI is perhaps the main reason that many software developers avoid code reviews.
Jason Cohen, the author of Best Kept Secrets of Peer Code Review argues that reviewing code
can have an excellent ROI if done correctly. The company he runs,
Smart Bear Software, is
currently giving away copies of his book for free, including shipping. At that price and considering
that it's a quick (164 pages) and painless read, you cannot go wrong. Naturally, there is a bit of a catch.
Smart Bear Software sells tools to help you conduct code reviews. So the book is basically
a way for them to get the word out on practices that they not only believe in, but
also have built a part of their business around.
Note: I have no vested interest (Updated: That was true when I originally wrote it in 2006, but in November 2008 I became an employee of Smart Bear Software) - I just like
in Smart Bear Software
d the book.
The book is much more than just a pitch for Smart Bear's products. It includes a brief history
of the research that has been done on reviewing (or inspecting) code, starting with the work
of Michael Fagan. There is considerable
coverage of more recent research, including a really
study of code reviewer eye movement.
The best thing about the book is that the research is distilled into practical advice and guidelines
for doing code reviews. Specific suggestions are given for how to conduct code reviews that
deliver the highest possible ROI, including information on which metrics to use for calculating
There were some things that seemed missing though. For example, in describing the checklists
that developers should use to self-inspect their code, it seemed like for many programming
langugages some of the items on the list could have been automated. The lack of a mention
left me wondering if maybe the author considers static analysis tools and the like to be
a bad idea. And there are some rough spots in the text: there are vague references in one chapter to content in some other chapter without the specific
chapter number, name, or page number. Finally, while most of the book is carefully footnoted, there
is one chapter with no footnotes and several statements such as: "In 2002 it was reported
that the average career in high-tech lasts 8 years." Okay, I might be willing to believe that, but only if I know the source.
In the end, though, those complaints are minor. The book is a worthwhile read. You
can pick up some valuable tips regardless of how you do code reviews.