Bulldozer00's Blog

Everyone and their brother, including BD00, thinks source code inspections are a best practice for detecting and eliminating defects before they burrow into your code to wreak havoc during expensive, downstream debugging debacles. There are reams of study data to support the efficiency of code reviews (relative to testing) in the battle of the bug. But, the world being as messy as it is, there’s a fly in the ointment. That fly is the cost required to, and this is important, “effectively” execute code reviews:

“And yet, at somewhere around 100 lines of code inspected per hour, it takes an investment of many hours to inspect even the smallest piece of software, say a couple of thousand of lines of code.”   – Facts And Fallacies Of SW Engineering, Robert Glass, P106

“There’s a sweet spot around 150 lines per hour that detects most of the bugs you’re going to find.” – The Art Of Designing Embedded Systems, Jack Gannsle, P21

Given these metrics, let’s concoct a concrete example so we can further investigate the cost issue :

Assuming the simple math is correct, the project manager in this example should “explicitly” allocate $200K and 4 calendar months of effort somewhere in his/her micro-managed Microsoft Project plan for our 100K line program, no?

The question is, when was the last time you saw a project plan that transparently and explicitly enumerated the time and cost for performing those code reviews mandated by your CMMI L3+ compliant process? If you haven’t seen such a plan, find out what kind of blowback you get from asking to have the resources required for “effective” code reviews embedded in your current or next prescriptive project plan. For even more drama, ask your QA group if there are any metrics (bugs found/review-hour, bug densities) that indicate how effective your code reviews are.

Since we’re having fun here, let’s go a little deeper into this undiscussable underworld by examining these two assumptions from our fabricated example:

• The reviewers are qualified and readily available: they understand the programming language(s) the code is written in; they have memorized the 200 page home-grown coding standards manual(s); they understand and have memorized the functional requirements the code is supposed to implement.
• The reviews are synchronized; the reviewers all start and end the code review at the same time.

Are these assumptions realistic? If not, then how do the budget and schedule numbers get affected?

Finally, in an iterative and incremental development process, when should code reviews take place? Piece-meal and disruptively after checking in each increment’s unit-tested code? In one big, formal she-bang after all the unit tests have passed?

How do you do code reviews, and how effective are they?