Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!lethe!geac!alias!pbreslin
From: pbreslin@alias.UUCP (Paul Breslin)
Newsgroups: comp.software-eng
Subject: Re: Prototyping and the Development Process
Message-ID: <1990Sep20.155115.3790@alias.uucp>
Date: 20 Sep 90 15:51:15 GMT
References: <3839@se-sd.SanDiego.NCR.COM> <33820@cup.portal.com> <1990Sep18.150322.17690@pdn.paradyne.com>
Sender: news@alias.uucp (USENET News)
Organization: Alias Research Inc., Toronto ON Canada
Lines: 31


>>I am very much interested in hearing about this as well.  It seems to me
>>that the problem with many rapid prototyping environments today is that
>>you have to throw away the prototype and re-code from scratch in C or
>>something similar.
>
>Brooks, "Mythical Man-Month" is well known for suggesting that a
>prototype be thrown away.  Evolution of a prototype into a product
>is a BAD THING and has been intimately related to the failure of
>projects I've worked on in the past.  Conventional wisdom is to throw
>out the prototype.  This is not a bug, it is a feature.  It allows
>the prototype to be brutally hacked together in a short period of time,
>and then tossed away allowing the programmers to *really* do it right
>the first time.
>

In my mind doing this eliminates one of the biggest advantages of
prototyping. Which is that you move incrementally towards a better and
better solution through an iterative design process. Re-building from
scratch is too costly and wasteful.

If you can't build quality and reusability into your prototypes from
the start, then chances are you won't/don't know how to "do it right"
when you start over from scratch.

"Hacking brutally" and "doing it right" just don't mix well (IMHO).
If you're into the former then you don't fully understand the latter.

I think the big trap to avoid is having the *first* prototype become
the final product. Management has a tendency to say "hey, it works,
let's ship it".