Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!ico!vail!sps
From: sps@ico.isc.com (Steve Shapland)
Newsgroups: comp.software-eng
Subject: Re: discarding prototypes
Summary: If you keep them, DOCUMENT them.
Message-ID: <1989Oct24.150941.505@ico.isc.com>
Date: 24 Oct 89 15:09:41 GMT
References: <1142@svx.SV.DG.COM> <34399@regenmeister.uucp> <5296@eos.UUCP> <14081@well.UUCP> <1989Oct19.021306.7336@ico.isc.com> <440.253dce97@devsim.mdcbbs.com>
Reply-To: sps@ico.ISC.COM (Steve Shapland)
Organization: Interactive Systems Corp., Boulder CO
Lines: 37

In article <440.253dce97@devsim.mdcbbs.com> jmi@devsim.mdcbbs.com
(JM Ivler - MDC - Douglas Aircraft Co. Long Beach CA.) writes:
>	We have developed a library of "tools and tricks" that
>	allows us to create prototype stubs and keep them around,
>	not only for ourselves, but for others to share with.

This works, provided you take the time to convert the prototype into
an internal product.  This means adhering to coding,
documentation, and source control standards for the library.
The documentation needs to be more complete than documentation for
your external product because of it's re-use intent.

The basic problem with prototypes is that they are often written
to prove a simple programming concept;
they do NOT provide sufficient robustness, error handling, or
documentation to qualify as production code.  Converting prototypes
to production quality code is often more difficult than re-writing.
Why? Because standards for things like variable names,
brace and indentation levels, error processing, have been left out
of the prototype development; the QUICK & DIRTY method.
A prototype usually follows the GIGO (garbage in, garbage out) rule,
instead of the GIRE (garbage in, report error) principle.

Now, once you have taken the time to standardize, document, and
store the prototype in your toolkit library,
it has become an internal product, and is no longer a prototype.

If you don't document it, the prototype becomes a piece of folklore,
contributing to the Parkenson principle of "data accumulating to
fill available space."  Two years from now, people won't know what
that prototype does, but will be afraid to delete it because it
might be important; instead they buy another disc drive.
Make the decision now,
invest in an internal product or throw away the prototype.

Steve Shapland
ico!sps (303)449-2870 x147