From: travis@eecs.nwu.edu (Travis Marlatte)
Subject: Re: Software Inspections.  How many does it take?
Organization: Rauland-Borg Corporation, Skokie IL
Date: Thu, 17 Dec 1992 23:10:20 GMT

In article <1992Dec14.192008.15480@gallant.apple.com> neumann.m@applelink.apple.com (mark neumann) writes:
>But what about module level design/code
>inspections, where the work being inspected is the result of one persons
>effort?

This is probably where one needs a review the most. One person designing
and coding a segment of code needs to have someone else check it out.

>It seems obvious that having someone check your work is a good idea.  It
>also seems that each additional person that checks your work is less
>likely to find a problem (on average).

This can be true if you invite people to a review just to fill in seating
space in the conference room. If, on the other hand, you invite people
who have expertise in specific areas, their collective perspective is
much broader than any one of them.
>
>My question:  Is one person enough?  Does anybody else use a single
>reviewer approach?

The approaches that one finds in the text books really deal with large
software projects. If I am designing and coding a major subsystem of
a large project, the interactions that my code will have with other parts
of the system and the outside world require me to invite a large number
of people to a review. Each one may have insight to a particular
interaction that none of the others does.

If I am making a small change or coding a small section that is fairly
confined in the system, I really only need to have one maybe two people
take a look at it. I'll probably throw a copy on their desk and ask them
to take a look at it.

>
>I believe that there are interpersonal dynamics which make one reviewer
>more effective than two of more.  With two or more people, the ego of the
>person whose work is being reviewed is more likely to become a factor.
>
>Finally, by assigning a single reviewer to inspect someone elses work,
>that person is obviously  responsible for any flaws that get through, so
>he/she is likely to take the role seriously. (Note: you probably do not
>want to assign people to inspect each other's work, since they may agree
>to just trust each other completely).

This is a big issue with reviews. An organization must mature to the point
where egos are not a problem. It only takes a couple of well run reviews
to get people used to the idea.

Having the reviewers sign off on a review to make them responsible is
good on paper but doesn't translate to anything in the real world.

In the end, when the bug gets reported, the person managing the code
will be responsible no matter who coded or reviewed it. Reviewers should
take the responsibility seriously with a desire to share their insight
to improve software quality. Authors should take suggestions graciously
with the same attitude.

Any discrepencies in attitude should be handled with philosophy not
policy. Noone should attend a review they don't want to be at. It is
a waste of time for him or her and counter-productive for everyone else.

-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
Newsgroups: comp.software-eng