Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!tivoli!alan
From: alan@tivoli.UUCP (Alan R. Weiss)
Newsgroups: comp.software-eng
Subject: Re: Code inspections
Message-ID: <371@tivoli.UUCP>
Date: 12 Feb 91 00:33:27 GMT
References: <14964@megatest.UUCP> <40530@genrad.UUCP> <7362@tekchips.LABS.TEK.COM> <29653@mimsy.umd.edu> <349@tivoli.UUCP> <3108.27aeae3b@iccgcc.decnet.ab.com> <7410@exodus.Eng.Sun.COM>
Reply-To: alan@tivoli.UUCP (Alan R. Weiss)
Organization: Tivoli Systems Inc., Austin, TX
Lines: 72

In article <7410@exodus.Eng.Sun.COM> donm@margot.Eng.Sun.COM (Don Miller) writes

>   There has also been no discussion on how to make most effective
>   use of the time and personnel resources allocated to code reviews.
>   Is everyone really still just giving out hard copy of source,
>   hoping reviewers can figure it out, and then getting together
>   to hammer it out?

Gilb's Inspections are NOT code reviews.  Tom Gilb's practices embody the
essencfe of good meeing management.  As both a technical person in SQA
AND a professional manager, I appreciate this.  So do our developers.


>   I envision a code review process which makes use of tools and
>   practices designed to minimize resource consumption.

Does this mean, "not wasting a lot of time?"

>  Static 
>   analysis tools would be valuable towards understanding foreign
>   code.  An on-line reviewer which cataloged comments of the
>   reviewer would facilitate pre-meeting information gathering.
>   A projection system accessing the actual code could be used
>   as a guide during the review.

Good ideas.  We use electronic mail extensively for pre-Defect Logging Meeting
and post-meeting discussions.

Since we're not actually inspecting code yet, I really like your idea of
an overhead projector.  However, as I said this is not a code walkthrough
or a code review.  Peole are expected to have read and commented on the
code beforehand.  The overhead would be used for clarification purposes
only.

>
>   I'm proposing automation, or even just optimal manual techniques,
>   as a way of addressing the primary concern regarding code reviews.
>   Some of the tools that I've mentioned above exist and the others
>   aren't difficult to imagine.  Does anyone out there use these
>   techniques or are we still in the stone age?
>
>--
>Don Miller                              |   #include <std.disclaimer>
>Software Quality Engineering            |   #define flame_retardent \
>Sun Microsystems, Inc.                  |   "I know you are but what am I?"
>donm@eng.sun.com                        |   

We software engineers are too often prone to suggesting technological
solutions for what is really a business organization problem:  not
wasting time, defining people's jobs in terms of a total engineering
perspective, getting people to Do The Right Thing, etc.  I would suggest,
IMHO, that none of these things can be solved by technology, only by
good management (including good self-management :-)



	.-------------------------------------------------------.
	|  Alan R. Weiss                                        |
	|  Manager, QA and Mfg.  _______________________________|
	|  Tivoli Systems, Inc.	| These thoughts are yours for  |
	|  Austin, Texas, US	| the taking, being generated   |
	|  512-794-9070		| by a program that has failed  |
	|  alan@tivoli.com	| the Turing Test. *value!=null;|
	|_______________________________________________________|
	|#include "std.disclaimer" --- Your mileage may vary!   |
	.-------------------------------------------------------.
 

"Quality is never an accident.  It is always the result of high intention,
sincere effort, intelligent direction, and skillful execution.  It represents
the wise choice of many alternatives."