Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.software-eng
Subject: Re: discarding prototypes
Message-ID: <1989Oct22.162619.2780@world.std.com>
Date: 22 Oct 89 16:26:19 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: madd@world.std.com
Organization: Software Tool & Die
Lines: 63

In article <440.253dce97@devsim.mdcbbs.com> jmi@devsim.mdcbbs.com (JM Ivler - MDC - Douglas Aircraft Co. Long Beach CA.) writes:
|> In article <14081@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
|> EVERY prototype should get tossed.
|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. [...] Never throw away the work. Put it
|in a library where others can view it and learn from it.

I don't think people are arguing about saving basic tools used in
prototypes, only about code used in REAL prototyping, where you are
building something to deal with a hitherto unknown or unused
technology.

In developing a prototype implementation of such a tool, even with
proper planning, you often end up with poor implementation because you
just didn't know what to expect.  On my last job I ran into just such
a thing.

A CASE tool had been designed around the company owner's own CASE
techniques, which differ somewhat from some of the standard
techniques.  This tool was obviously prototype-class, yet it was
marketed and sold as product.  Customers had to deal with
prototype-class problems (many crashes, lost data, etc) and
maintenance was virtually impossible.

*This* is what most software engineers, including myself, mean when
they say "always toss the prototype".  The core of an experimental
system can almost always be improved.

In _Mythical_Man_Month_, p. 116, Brooks says:

"In most projects, the first system built is barely usable.  It may be
too slow, too big, awkard to use, or all three.  There is no
alternative but to start again, smarting but smarter, and build a
redesigned version in which these problems are solved.  The discard
and redesign may be done in one lump, or it may be done
piece-by-piece.  But all large-system experience shows that it will be
done.(2)  Where a new system concept or new technology is used, one
has to build a system to throw away, for even the best planning is not
so omniscient as to get it right the first time.

"The management question, therefore, is not *whether* to build a pilot
system and throw it away.  You *will* do that.  The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers.  Seen this way, the answer is much
clearer.  Delivering the throwaway to customers buys time, but it does
so only at the cost of agony for the user, distraction for the
builders while they do the redesign, and a bad reputation for the
product that the best redesign will find hard to live down.

"Hence *plan to throw one away; you will, anyhow.*"

The footnote is:

(2)An illuminating account of Multics experience on two successive
systems is in F.J. Corbato, J.H. Saltzer, and C.T. Clingen, "Multics
-- the first seven years," AFIPS Proc SJCC, 40 (1972), pp. 571-583.

My experience, and that of others I have worked with, bears this out.

jim frost
software tool & die
madd@std.com