Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!felix!asylvain@felix.UUCP
From: asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain)
Newsgroups: comp.software-eng
Subject: Re: Code inspections
Message-ID: <156342@felix.UUCP>
Date: 30 Jan 91 01:51:15 GMT
References: <14964@megatest.UUCP>
Sender: daemon@felix.UUCP
Reply-To: asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain)
Organization: Foundation for the Advancement of Chipmunks
Lines: 64

In article <14964@megatest.UUCP> pat@megatest.UUCP (Patrick Powers) writes:
> It seems that the problem with code inspections is largely emotional.
> Though there is plenty of evidence that code inspections are cost
> effective, I believe they would tend to be boring and stressful.
> Boring because they are a time consuming and non-creative activity --
> current issue of IEEE Software recommends 150 lines of code reviewed
> per man-day as a good figure.  I know I would not want to do this, and
> who would?  Stressful because it is out of the programmer's control,
> and because criticism is involved.  People identify closely with their
> creations and find criticism painful.

Any kind of criticism must be tempered by the fact that, regardless of
how "lone wolfish" the programmer may be, s/he is ultimately part of a
team.  It is the team which reviews the work, and the team which finds
problems.

Personality conflicts are a management problem, including letting the
people know that all criticism _shall be_ viewed constructively.

[...]
> In order to reduce these problems the following has been suggested:
> 1) The author not be present at the inspection

No, the author must be there.  If s/he can't handle criticism, espe-
cially in a team context such as this, s/he needs to grow up some.
Again, this is part of management's job, to make sure that everyone
knows:
   (a) Everybody makes mistakes, including You,
   (b) We are earnestly looking for All mistakes, including Yours, so we
       can remove them, and
   (c) When we find Your mistakes, it doesn't mean You're Stupid or that
       We Don't Love You.  It just means that you fall into category (a)
       like the rest of us, and, hallelujah, we succeeded in category (b).

> 2) Only errors are communicated to the author.  No criticism of style allowed.

I agree with this to a degree.  If the style is making understanding
difficult, that is a valid point to bring up with the author.  Badly
spaghettied code, for example, must be avoided unless absolutely neces-
sary.  Inconsistent style can lead to errors in understanding, and
again, must be avoided.

> I've toyed with the idea of instituting code inspections but just
> couldn't bear to be the instrument of a good deal of unhappiness.
[...]

I assume then that you are in management.  Therefore, it is up to you to
mitigate this unhappiness.  Believe me, it *can* be done.  I suspect
that even the lonliest programmer appreciates an excuse to crawl out
from under the terminal, so long s/he feels there is a valid reason
to do so.  Finding and removing errors is a valid reason.  Perfecting
the team product is a valid reason.

Just let them know that the criticism _shall be_ constructive, and that
it _shall be_ rendered in a professional manner.  No "nyahh-nyahh's"
allowed!
--
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain)
=========== Opinions are Mine, Typos belong to /usr/ucb/vi ===========
"We're sorry, but the reality you have dialed is no longer in service.
Please check the value of pi, or see your SysOp for assistance."
=============== Factual Errors belong to /usr/local/rn ===============
UUCP: uunet!{hplabs,fiuggi,dhw68k,pyramid}!felix!asylvain
ARPA: {same choices}!felix!asylvain@uunet.uu.net