Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!ux1.cso.uiuc.edu!cs.uiuc.edu!marick
From: marick@cs.uiuc.edu (Brian Marick)
Newsgroups: comp.software-eng
Subject: Re: Code Inspections
Message-ID: <1991Feb6.143922.20539@cs.uiuc.edu>
Date: 6 Feb 91 14:39:22 GMT
References: <15469.9102041851@olympus.cs.hull.ac.uk> <DWWX.91Feb5231734@cbnewsk.ATT.COM>
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Lines: 31

dwwx@cbnewsk.ATT.COM (david.w.wood) writes:
>Is it so obvious that nobody thinks it needs to be stated?

I hope so.  Inspections (of some sort) are, as you say, more important
for upstream products than for code, both because you find important
errors sooner, and also because there are precious few alternatives.

There are at least two, though:

1.  It's been my experience (and other people's, too) that writing
test cases tends to find errors in the specification/design.  I think
it's because test cases are "concrete" -- you must specify exact
inputs and outputs, with no vagueness about what actually happens.
It's then that you realize that *that* module's output can't possibly
fit with *this* module's input.

2.  I've found that writing the user's manual also tends to flush out
errors in a specification.  I think this is because it makes you
approach the specification from a different perspective -- a good
user's manual explains the "why" of the specification.  It has to,
because it must give the reader an understanding of the fundamentals;
without that, he or she won't be able to extrapolate from your
examples.  Sometimes, you discover that the "why" doesn't make sense.
(Note:  I've had good results doing this, but others have not.)

Because of this, I like to write the test cases and user documentation
well before I write the code.

Brian Marick
Motorola @ University of Illinois
marick@cs.uiuc.edu, uiucdcs!marick


Brought to you by Super Global Mega Corp .com