Lightweight Code Reviews A Lightweight Alternative to Inspections


the Inspection Phase. The Moderator sets the pace of this meeting and makes sure everyone is performing their role and not ruining anything with personal attacks. The Reader presents the Materials because it was his job to "read for comprehension" since often someone else's misunderstanding indicates a fault in the Materials. During the meeting a Defect Log is kept so the Author will know what needs to be fixed. Before the meeting ends they complete a rubric that will help with later process improvement.

If defects were found the inspection enters the Rework Phase where the Author fixes the problems, and later there will be a Verification Phase to make sure the fixes were appropriate and didn't open new defects. Finally the inspection can enter the Completed Phase. can let it out now
The good news is, this works. It uncovers defects, it helps when training new hires, and the whole process can be measured for process insight and improvement. If you have extra money laying around in your dev budget, Mr. Fagan himself will even come show you how to do it.

The bad news should be obvious in this day of Agile Methodologies. Studies show that the average inspection takes 9 man-hours per 200 lines of code, so of course Mr. CTO couldn't do this for every code change in the company.

Over the years there have been experiments, case studies, and books on this subject, almost always using some form of "code inspection" as the basis. In our survey of published case studies and experiments in the past 20 years, we found that 95% of them tried inspections only in small pilot groups, and that in no case were they able to apply the technique to all their software development projects.

If "Agile" can do it, why can't we?
But surely there is another way. Fagan inspections were designed in the days when business logic was written in assembly language and "computer science" wasn't a major and dinosaurs roamed the earth.

Have we learned nothing since then? Don't we need different techniques when reading object-oriented code in a 3-tier application? Don't the challenges of off-shore development require new processes? Hasn't the rise of Agile Methodologies shown us that we can have process and metrics and measurement and improvement and happy developers all at the same time?

E-mail isn't enough
Of course other ways exist. Most of them are (rightfully) rejected by the process community because they are typically unmeasurable and uncontrollable. For example, many groups have their version control server email code-diffs every time something is checked in. Those developers responsible for that code — or just interested — have a chance to look it over, start conversations about it, and possibly to open issues to have someone fix something that isn't right.

But whether your reviews are by email, by developers standing over each other's shoulders, or something similarly informal, how do you know whether all your code has been reviewed? If defects are discovered and authors are told, how do you know whether authors really do fix the defects? How much time do developers and reviewers spend locating, opening, and jumping to "line 732 of file //depot/foo/bar/baz/" and then running back to Outlook to make a comment? How does a reviewer manage the 50 reviews that pile up because each takes seven days because the author is in Taipei and every question takes 12 hours to answer? And then the higher-level questions: How much time are developers spending during review? How many defects are they finding per 1000 lines of code or per hour?

About the author

Jason Cohen's picture Jason Cohen

Jason Cohen is the author of Best Kept Secrets of Peer Code Review, the definitive work on the new process of Lightweight peer review with 7,000 copies in circulation. Jason conducted and published the largest case study of peer code review at Cisco Systems®—2,500 reviews over 10 months with a real, delivered product. Jason is also the founder of Smart Bear Inc., makers of Code Collaborator that assists developers and managers with lightweight peer code review processes. Jason has spoken at many conferences, trade shows, and ACM/IEEE society meetings across the country.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!