rcd@ico.isc.com (Dick Dunn) (10/19/89)
In article <14081@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > +-- 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?... It's not necessarily the characteristics of the prototype itself so much as a "matter of principle" (a phrase which often suggests "no good reason":-) to protect the process of prototyping. If you want to be able to use prototyping, you have to know that when you create a prototype, it's going to be just that. Even if it does its job well, it may not have the sort of internal characteristics that will let it survive maintenance and adaptation. Even if it has those as well, you have to spend some time checking it over from the criteria of production programs. That's why I'd say throw it out as a matter of principle. EVERY prototype should get tossed. (Then you can sneak in when nobody's looking and scavenge the pieces you can use in the real thing...:-) By protecting the process of prototyping, I intend first that NOBODY outside the team responsible for implementing the "real" software should ever even begin to ponder the possibility of hinting at broaching the suggestion of considering turning the prototype into production code-- that allows the prototyping process to be corrupted from outside. Nor should the implementation team itself consider using the prototype, because that may allow the idea of prototype->production to take root. They may also delude themselves into thinking they can use something they really shouldn't. However, since I never ever make ironclad rules, I'll admit that there is a remote possibility that occasionally some significant piece of a prototype can be used in production. If you do it, don't blab it around, OK? It'll come back to haunt you. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
jmi@devsim.mdcbbs.com (JM Ivler - MDC - Douglas Aircraft Co. Long Beach CA.) (10/19/89)
In article <1989Oct19.021306.7336@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > In article <14081@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > > That's why I'd say throw it out as a matter of principle. EVERY prototype > should get tossed. (Then you can sneak in when nobody's looking and > scavenge the pieces you can use in the real thing...:-) > > -- > Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 > ...No DOS. UNIX. Hate to disagree, but... 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. Examples of how this has been benificial (and therefore saved the company money) is a simple routine that accessed a logical value to determine what callable editor should be used from within a program was prototyped for one process. The section of code that dealt with the logical symbol has now appeared in two other prototypes and the callable editor functionality will be used to allow users entering in formatted reports to have the entire report come up in the LSE (a DEC layered product) editor with a predefined template. Not bad for a simple piece of throwaway code. Never throw away the work. Put it in a library where others can view it and learn from it. This is not school where you get a lower grade from using things in others work. This is the real world, where the dollars and cents do make a difference. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | J.M. Ivler | INTERNET: JMI@DEVSIM.MDCBBS.COM | | McDonnell Douglas Corp. | UUCP Bang: UUCP!DEVSIM.MDCBBS.COM!JMI | | Douglas Aircraft Co. |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 3855 Lakewood Blvd | VOICE: (213) 496-8727 | | Mail-stop 36-49 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Long Beach, CA 90846 | DECUServe and DCS available (IVLER) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | DECUS - L&T SIG/ CASE and Tools Integration Working Group Chair | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Toolsmith (n) - a specialist in the manufacture of support software
madd@world.std.com (jim frost) (10/22/89)
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
jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.) (10/24/89)
In article <1989Oct22.162619.2780@world.std.com>, madd@world.std.com (jim frost) writes: > 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. > I was seeing quite alot of "throw out the baby with the bathwater" mentality. Rapid prototyping provides a foundation for determining untried design concepts. It is *not* deliverable code, just the stub concept. We keep it around so others can learn from one engineers experiences. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | J.M. Ivler | INTERNET: JMI@DEVSIM.MDCBBS.COM | | McDonnell Douglas Corp. | UUCP Bang: UUCP!DEVSIM.MDCBBS.COM!JMI | | Douglas Aircraft Co. |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 3855 Lakewood Blvd | VOICE: (213) 496-8727 | | Mail-stop 36-49 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Long Beach, CA 90846 | DECUServe and DCS available (IVLER) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | DECUS - L&T SIG/ CASE and Tools Integration Working Group Chair | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Toolsmith (n) - a specialist in the manufacture of support software
sps@ico.isc.com (Steve Shapland) (10/24/89)
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