Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.software-eng Subject: Re: Information Systems is an Engineering Discipline Message-ID: <14081@well.UUCP> Date: 13 Oct 89 04:34:00 GMT References: <1142@svx.SV.DG.COM> <34399@regenmeister.uucp> <5296@eos.UUCP> <568@pd1.ccd.harris.com> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Distribution: comp.edu Organization: The Blue Planet Lines: 33 +-- bill@pd1.ccd.harris.com (Bill Davis) writes: | In article <> ejp@abvax.icd.ab.com (Ed Prochak) writes: | >Prototypes have to be treated as throw-aways, | >especially when they work! | | I agree with throwing away prototypes when appropriate. | But, what makes a prototype something that should be | thrown away if it is working and providing useful | functions? Is it because it has "lower quality" or | because it has bugs? No. Prototypes should be treated as a design lab. The original paper design invariably gets changed when being implemented, as concerns and collisions appear that were masked in the "pure thought" stage. As result, prototypes tend to be a Krazy Kwilt (tm) of patchs and partially abandoned approaches. Once the problem is fully understood, however, the experiment should be thrown away and the real system built. Why? Not because the prototype doesn't work, but because the design is bad. The first implementation of any program is, by definition, a prototype. The real problem is that many so-called products are really prototypes. | I use lots of software with | bugs and the variation in "quality" is large. | But, this "buggy" software still provides useful | functions to me when I avoid the bugs. Functionality is only a part of the picture. The rest of the picture includes reliability, support and enhancements. A good design makes this part of the process infinitely easier. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)