So
Why isn’t Everyone Using Inspections

If
Inspections provide significant benefit, why has adoption been so slow? Why is
not all of the software community using the method? The publicly published data
twenty-four years ago clearly demonstrated their effectiveness, and recent
reports continue to demonstrate their effectiveness. Why have Inspections not
taken a firmer root and achieved wider use?

The
reasons for this vary. I believe this is partially due to views that
Inspections can only be done one way. This book will eliminate at least some of
this misunderstanding. Another reason for the resistance to Inspections is the
view that they are not easy to do well. There are factors, including social and
psychological, that we must consider. Management often views Inspections as an
added cost, when in fact Inspections will reduce costs during a project. We
will see throughout this book how Inspections save both cost and time.

Since
the inception of Inspections, with the advent of each new development tool or
language, the providers and users seem to believe that Inspections do not add
value or are less necessary. This is clearly not true, since programmers still
make defects with these tools and languages. However there often is little
documentation as to how well Inspections work in these new environments, so a
false belief that Inspections do not apply may be propagated by myth. We will see later in the book that Inspections do apply in these
development environments also.

Because
of these and other factors, shortcuts in the Inspection process have been taken
without any proof that the change is an improvement. Some of these home grown
changes cause the Inspection process to be less effective. In turn the value of
what was defined as the Inspection process is diminished. Thus failure becomes
a self-proving “fact.”

Inspections
may not be the most enjoyable engineering task compared to designing and
coding. Also, programmers are very possessive about artifacts they create.
Inspections are labour intensive and low tech, but they do work.

. Can Inspections Replace Test?

 Inspections are low tech, labour intensive,
and rarely fun. These among other factors cause people to question the value of
Inspections. A frequent challenge is put forward that some form of testing;
i.e., unit test, will be just as effective and efficient or that Inspection
cannot catch all defects.

I
previously discussed that the solution for a defect is usually evident when it
is found during an Inspection, thus the costs for repair are minimized. Tests
after unit test do not make readily identifiable the area requiring repair and
thus the costs increase. The countless attempts to prove that unit test is more
efficient have failed and I know of no study that has been repeated where unit
test has been demonstrated to be as effective as Inspections in removing
defects.

If it
is accepted that Inspections have value, the next challenge voiced about
Inspections is that unit test in combination with code Inspections will lead to
better results. Again, every trial I know of has failed in this regard. Russell
RUS91 gives two other reasons for not testing before Inspections:

1.       
As Inspections require a motivated team, testing first may lead to
a view that the code is reasonably stable and the team will be less motivated
to perform the best Inspection.

2.       
With the investment of test the Producer may be less receptive to
major rework on an “already-stable program image” which will also
require retesting.

Ackerman
found that the savings from defect detection costs in Inspections was 2.2 hours
compared to 4.5 hours in unit test. A two to one savings is a good place to
bank. In another organization he states a 1.4 to 8.5 staff hour relationship in
finding defects with Inspections versus testing. ACK89

Weller
WEL93 states that there are disadvantages of inspecting after unit test:

Unit test leads programmers to have
false confidence that the product works, so why inspectIt is a hard decision to inspect a
large batch that has been unit tested and there may be the view that there
is no longer time to inspect

He also
gives reasons to perform Inspections first:

You may actually be able to bypass unit
test if the Inspection results are goodYou can recover earlier with lower cost
to serious design defects found in Inspections versus unit test

Despite
this (and other) clear evidence, to this day many will suggest that unit test
should be done before Inspections. Always this has proven to be less efficient.
When I run into people who are hard to convince, I suggest that they try a
simple experiment to see what the data tells them. I remain fully objective and
state, “If the data proves that unit test before a code inspection is cost
effective, then by all means proceed.” Twenty-eight years of requests and
I have not been given proof that unit test is less costly. This does not mean
the experiments should never be tried again. I discuss more on this in Chapter
14. For now I’ll leave the door open suggesting that as technology evolves, so
too might the best way to remove defects.