Page 89 -

Each inspector should keep in mind the fact that if he did not understand something after
reading a document, then it is probably the document’s fault, not the reader’s. If he did
not understand it, then it is likely that another reader will also have the same problem
(especially considering that most software documents will be used as reference later, by
people who are less familiar with the project than the inspectors). For this reason, it is
very important that inspectors make it clear when they do not understand something.
This is difficult for many inspectors: it’s hard for people to admit that they did not under-
stand something that they have read. It is the moderator’s job to draw these misunder-
standings out of the inspectors during the discussions of each defect.
The author should be prepared to listen to the inspection team discuss defects. It is tempt-
ing to get defensive and try to defend each defect. The author must remember that if
someone thinks that an issue is worth bringing up in the meeting, there may be some
ambiguity there, no matter how clear it seems to the person who wrote the words.

One way to help the author feel less defensive is to take the option (described above, under
“Preparation”) in which the inspection team members submit their defects to the moderator
before the inspection meeting. The moderator compiles all of the defects into a log, which is
then sent back to the inspection team. This is helpful because it gives the author advance
warning of all of the defects that will be discussed. It also allows the inspection team to pre-
pare solutions to the defects in advance. However, it requires more effort on the part of the
moderator, who has to look through all of the defects up front in order to group redundant
defects together and make sure that each one is described clearly.
In some organizations, project managers have found it useful to require that the authors
not talk in the inspection meetings, to let the document stand on its own. In others, the
author is excluded from the meeting entirely, and is simply given the inspection log.
Although this sounds drastic and impersonal to some people, some moderators have
found this to be a very useful practice, as the team feels that they must put a lot of effort
into making the inspection log as self-explanatory as possible. However, while these prac-
tices do prevent the author from skewing the results of the inspection, they also cause the
author to miss out on important discussions; this is a costly trade-off. As long as the author
is able to listen to the moderator’s rules, especially when it comes to identifying and

addressing defects, he can be a valuable participant in the inspection process.
Help Others in the Organization Accept Inspections
Over the many years that inspections have been practiced in software organizations,
project managers have often found that when they attempt to implement inspections, the
team pushes back. This opposition occurs because, to some people, it is not intuitively
obvious that spending the time inspecting the work products up front will save the team
from having to fix the software later. The project manager should prepare for potential
resistance by understanding exactly why inspections are important.
Project managers often find that engineers are very unhappy with the idea of inspections.
To some, inspections seem unnecessarily “bureaucratic.” This is especially unfortunate

REVIEWS 81