Lots of things in the software field have been labeled as "breakthroughs." Invariably, they are not! Inspections, on the other hand, have never been labeled as breakthroughs. But the reality is, they nearly are! Here are some surprising thoughts on what inspections are, and how to perform them effectively.
Probably the biggest plague on the house of software is hype. All too many new techniques and technologies are hyped by their advocates as being the most important new approaches to hit the profession. It happened with 4GLs ("Programming Without Programmers"), CASE tools, object-orientation, Java... and the list goes on. Name your recent software concept and someone probably hyped it. It makes you wonder whether any new ideas are worth anything at all.
Meanwhile, quietly, off in the wings, there is one technology that really is worth some of those hyped claims, but no one is making any exaggerated claims for it at all! "What's that technology?" you're probably asking. It's inspections. Yes, inspections. That old-fashioned technology that we've known about for more than thirty years!
What's so great about inspections? Research study after research study shows that inspections are a better, faster, cheaper way of finding errors in a software product than any of the alternatives. Better than testing. Better than fault-tolerant code.
That doesn't mean that, if you do inspections, you don't need to use any other error-removal approaches. Testing still has a very important role to play, as enterprises that have tried to eliminate it in favor of alternatives have learned the hard way.
Now, what do those research studies show us? That by using inspections properly, more than 90 percent of the errors can be removed from a software product before its first test case is run. That's pretty impressive stuff, and though I doubt the researchers can ever be sure that 90 percent of software errors have been found (that implies they know how many errors are present in total, which is unlikely!), it's clear that more errors were found-more cheaply-by inspections than by any other technique.
At one company having problems with multitudes of undetected software errors, I recommended (as you might expect) that they use inspections. When I followed up some months later, I found that they had, indeed, begun using inspections, and that the incidence of errors was way down. But I was not quite prepared for what the cause of that change had been. It wasn't that the inspections were identifying tons of software errors. But the programmers, knowing that their code was going to be inspected, were poring over it in advance of the inspections and finding most of the errors beforehand.
Fine. If inspections cause a reduction in the number of errors, who am I to care whether that happens at the inspection or beforehand?
So how do you conduct an effective inspection? If you're guessing that I'm going to advocate the well-known Fagan approach to inspections…guess again!
The Fagan inspection, as you may know, is a process-focused inspection. Inspectors are assigned roles and are trained in how to play those roles in the inspection meeting. Meeting goals and processes are rigorously defined. There are meeting rules, and the rules are enforced.
I believe that the product rather than the process should matter most in inspections. And that naturally raises the question: Is there a kind of inspection that is product focused?
Product, Not Process
The answer is "yes." For example, Rifkin and Deimel-several years ago in an SEI-funded study-came up with a way of conducting inspections where the pre-meeting training was in code-reading approaches, rather than meeting process. They tested the two approaches against each other and found that there were "spectacular" benefits to the new approach. Code-focused inspectors were finding 90 percent more errors than process-focused inspectors.
Porter and Votta came up with another approach (they presented it at the 1994 meeting of the NASA-Goddard Software Engineering