Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!caen!umich!dgsi!wags
From: wags@cimage.com (Bill Wagner)
Newsgroups: comp.software-eng
Subject: Re: Code inspections
Keywords: inspection, software engineering
Message-ID: <1991Jan29.203421.1236@cimage.com>
Date: 29 Jan 91 20:34:21 GMT
References: <14964@megatest.UUCP> <40530@genrad.UUCP> <7362@tekchips.LABS.TEK.COM>
Reply-To: wags@cimage.com (Bill Wagner/10000)
Organization: Cimage Corp, Ann Arbor, MI
Lines: 61

In article <7362@tekchips.LABS.TEK.COM> rjn@crl.labs.tek.com (Jim Nusbaum) writes:
>[reference from earlier post deleted]

>I just don't see this as being realistic.  What other job where a product
>(software in this case) is produced do you find people not being judged on
>the quality of their output?  People absolutely have to be judged on how well
>they perform their jobs and if putting out high quality software is their
>job then their manager should be able to measure their job performance and
>react accordingly.
>
>I find the attitude expressed in the above two postings very disturbing.  They
>seem to imply that people involved in software production somehow need to be
>treated very differently from people involved in other types of production.
>You aren't allowed to measure their work, you can't judge their work, you
>can't evaluate their job performance based on their work.  This kind of
>thinking is what is keeping software from becoming a true engineering
>discipline and it is why so much software is so bad.  Programmers need to
>realize that their job is producing high quality software, not just a
>program that "works".  They need to be held accountable for their work.
>I have found that true professionals don't mind code inspections and
>walkthroughs, because they are confident in their ability and proud of
>their work.
>
Your post seems to be combining two justifications for code inspections
into one.  When I have had my code inspected, it was to happen before
any testing of the code took place, (by definition, after the first
clean compile).  The justification for that was that other experienced
programmers could spot errors and suggest small - scale design improvements
before testing occurred.  (Major design suggestions should have already
been received at design reviews).  The end results were: 
1.  smaller, faster code
2.  less time spent debugging.

1. is a little tough to justify, but I believe it based on changes I 
made or suggested.  

2.  is easy to justify.  Any logic errors found before testing begins
is less time spent in the debugger, and in testing - > fixing -> re-
testing cycle.  

Now, if you wish to examine my (or anyone else's code) for 
judging the quality of work, I'd rather it was done after the 
testing cycle.  That way, you are judging the completed code,
as opposed to a first draft.  

I agree that programmer's need to accept responsibility for the 
quality of their work, but forced examinations aren't the best 
way for that to happen.  The idea of a review (whether it be a 
design review, or a code review) is to allow peers the oportunity
to comment on the proposed solution to a technical problem.  The
reviews should remain just that.  Now, if you wish to measure a 
programmer's performance based on the quality of code that the 
programmer has agreed is ready to be released, that is another
matter entirely.


-- 
          Bill Wagner                USPS net: Cimage Corporation
Internet: wags@cimage.com                      3885 Research Park Dr.
AT&Tnet:  (313)-761-6523                       Ann Arbor MI 48108
FaxNet:   (313)-761-6551