Wednesday, October 25, 2006

Code Review vs. Code Inspection

Can we skip code inspection process?

In his novel, The Deadline, Tom DeMarco gives an interesting sample about reducing project development time by removing verification stage from the development process. Well, I'm sure it's possible for an excellent team, but unfortunately it's still too extreme for most of project teams in the real world.

However, code inspection process is a bit different thing.

Can you imaging that experienced developer, who always created exemplary code, will start working in a slapdash manner? Yes, if that person has some personal problems, is bored by the project, has a conflict with another team member, or the like. But it's all about management, not about programming.

Professionals, who keep working in the same area, won't lose their knowledge and experience! Thus, there is no need to continue inspecting project code if several recent reviews confirmed that the code is in good condition. It's just waste of time, nothing more.


Code Review vs. Code Inspection?

It's a common thing, to mix Code Review and Code Inspection terms. However, these two process have different goals. While Code Inspection is focused on verification that source code corresponds to coding rules, guidelines, and has no obvious smells; Code Review helps finding defects and creating a base for code refactoring.

Most areas of code inspection process can be automated (e.g. Static code analysis). Code review can not. In fact, this is a cornerstone of code reviews - using a human brain to read and understand the code, looking for defects with a fresh eye. Peer code reviews remain the best approach for finding code defects (Sergei Sokolov. Bulletproofing C++ Code. Dr. Dobb’s Portal, January 09, 2006).

On average, 60 percent of defects can be removed via code reviews (Barry Boehm, Victor R. Basili. Software Defect Reduction Top 10 List. CeBASE, January 2001), so it's really helpful to introduce regular code review process when the code is being actively created.

2 comments:

Clayton Weimer said...

On average, 60 percent of defects can be removed via code reviews" - Boehm
Not true, and the original statement referenced was from Boehm's 1987 paper http://sunset.usc.edu/csse/TECHRPTS/1985/usccse85-499/usccse85-499.pdf
which actually said "structured walkthough and code inspections" not "code review". There was no data provided to back this up BTW, however it is well known through many studies, even by 1987, code inspections can provide these results and this is like what Boehm was primarily referring to.

However this invalidates your premise.

Serge Stepantsov said...

Honestly, I didn't see that original top ten list before, and I was referring to revised version published in 2001. In that article Barry Boehm and Victor R. Basili refer to some numerous
studies which "confirm that peer review provides an effective technique that catches from 31 to 93 percent of the defects, with a
median of around 60 percent.
"

In that 2001 article, they also replaced structured walkthough and code inspections with peer reviews, leaving formal code verification to automated analysis tools.

Anyway, Clayton, thank you very much for your comment! I've been under impression that this topic is not actual anymore, because all project teams I'm working with do not use code inspection checklists for some years. They use code analysis tools to verify code style and to detect common anti-patterns, while peer review is focused on implementation aspects and knowledge sharing.

It will be very interesting and probably useful to know about projects that are using manual code inspection techniques, and to compare the results.