Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!bellcore!faline!scherzo!allegra!mit-eddie!husc6!seismo!mcvax!ukc!its63b!bct
From: bct@its63b.UUCP
Newsgroups: comp.arch
Subject: Re: catering to bad code
Message-ID: <304@its63b.ed.ac.uk>
Date: Wed, 4-Mar-87 05:08:31 EST
Article-I.D.: its63b.304
Posted: Wed Mar  4 05:08:31 1987
Date-Received: Sat, 7-Mar-87 01:08:54 EST
References: <14833@amdcad.UUCP> <14837@amdcad.UUCP> <436@cpocd2.UUCP> <64@celerity.UUCP> <15014@amdcad.UUCP>
Reply-To: bct@ecsvax.ed.ac.uk (B Tompsett)
Distribution: world
Organization: Dept. of Computer Science, Edinburgh University, U.K.
Lines: 52
Summary: No such thing as throw-away.

In article <15014@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>I'm glad to see some people are mildly interested in this subject. :-)
>I didn't make very clear the purpose of the Unix system I'm designing.
>It is intended to be a throw-away. We only want to bring it up to show
>that Unix can be brought up, and to see how fast it runs.  We don't
>intend to sell this software as a product. As such, our only interest
>is in doing it fast and to be able to run as much existing software as
>possible. 
>
>-- 
> I'd rather be compatible than right.
>

 Did the nice marketing man with a suit and tie tell you the bit about
"..intended to be a throw-away. We only want to bring it up to show that .."?

 They do that to all the systems people all the time. Hardware people get it 
too. "..just put this MC68020 on a board to show that we can do it..", and
 before you know it the company has a new product.

  Where I worked (a large corporation in New England) they always sung me 
the just a "throw away" line. There's no such thing. When it's done someone
will like it and buy it. Then you'll have to maintain it. If not you then
someone else will get the job. You'll get bug reports complaining about bugs
you knew were there all the time. You'll get bug reports about features. 
You'll write accurate documentation explaining how it's all a kludge, and the
editors will expunge those bits. The millstone will be around your neck for
years and years.

 Do it properly the first time. Do it properly everytime. Do a job to be 
proud of. Make checking segment violations the default behaviour, make it
hard to turn them off. [But put a way of turning them off, just to save your
ass]. I recomend turning off the segementation violations/memory violations
or whatever in the software and have them always flagged by hardware.

 Don't you ever wonder how so much of the stuff out there is pure junk? Its 
the marketing people telling you ".. it's just this little demo... after the
show we can put it right..". It never gets put right, they put you on a new
project before your feet hit the floor.

  Brian
-- 
> Brian Tompsett. Department of Computer Science, University of Edinburgh    <
>                   JMCB, The King's Buildings, Mayfield Road, Edinburgh,
>                        Scotland, EH9 3JZ.
>E-Mail:     JANET: bct@uk.ac.ed.ecsvax
>           USENET: bct@ecsvax.ed.ac.uk
>             UUCP: seismo!mcvax!ukc!ecsvax.ed.ac.uk!bct
>             ARPA: bct%ecsvax.ed.ac.uk@ucl-cs
>           BITNET: psuvax1.bitnet!ecsvax.ed.ac.uk!bct
>                or bct%uk.ac.ed.ecsvax@earn.rl.ac.uk
>Phone:  +44 31 667 1081 x 3332