Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!hpcupt1!hpirs!runyan
From: runyan@hpirs.HP.COM (Mark Runyan)
Newsgroups: comp.software-eng
Subject: Re: code reviews
Message-ID: <9630006@hpirs.HP.COM>
Date: 25 Jun 89 22:31:02 GMT
References: <8906161716.AA16121@kronos.ADS.COM>
Organization: HP GSY/USO/UKL Cupertino, CA, USA
Lines: 22

>/ stein@pixelpump.osc.edu (Rick 'Transputer' Stein) /  7:53 am  Jun 19, 1989 /
>...  Code walkthroughs, design reviews, acceptance testing, etc.
>are all part of the software engineering process.  These elements provide
>accountability, and this is a necessary part of any environment where
>funds are spent developing a product.  The activities are _part_ of the
>process, and while considered a nuisance by some, are invaluable tools
>for management.

My posting probably isn't going to sound like it, but I am a believer in
code walkthroughs, etc.  However, it surprises me how little this is done
in the industry (or, at least, at companies that I've been in).  Sometimes
the project is so uncomplicated that code reviews are considered
unnecessary, while at other times, managers and engineers resist code
reviews because of the fear of an "elitist" attitude (in this case, it
isn't a peer review, but an owner review, i.e. "you" can't put it into "my"
code unless "you" check with "me" first).  There are right ways and wrong
ways to implement design and code reviews, and the wrong way is usually
taken when the the implementer doesn't understand what the review is suppose
to do, but is instead implementing some cookbook method from some software
engineering course.

Mark Runyan