Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!fernwood!portal!gdc!foster From: foster@gdc.portal.com (Sharon Foster) Newsgroups: comp.software-eng Subject: Re: Effect of execution-speed on reliability/testing Message-ID: <1541@gdc.portal.com> Date: 8 Jan 91 12:56:58 GMT References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <826@gdc.portal.com> <14141@uswat.UUCP> Organization: General DataComm, Middlebury CT Lines: 45 In article <14141@uswat.UUCP>, gbeary@uswat.uswest.com (Greg Beary) writes: > In article <826@gdc.portal.com> foster@gdc.portal.com (Sharon Foster) writes: > > .... Stuff Deleted >>> which states that ``speed is not important''? >>> >>> -- Bertrand Meyer >>> bertrand@eiffel.com >> >>How about Michael A. Jackson's two rules of optimization: >> >>Rule 1: Don't do it. >> >>Rule 2: Don't do it yet. >> >>from _Principles of Program Design_, chapter 12. >> >> > > My personal experience in realtime systems is just the opposite, and > just as mis-leading. When working for a IBM-compatible hardware company > the Disk-folks were selecting new micro-processors. The criteria was > "the fastest is the best". > > This begged the question, "how fast does it have to be". The answer was > "as fast as we can get". I think we need to add a healthy dose of > engineering into this discussion, so we can understand "how fast does it > have to be". > > > > -- > Greg Beary | (303)889-7935 > US West Advanced Technology | gbeary@uswest.com > 6200 S. Quebec St. | > Englewood, CO 80111 | Well, I didn't say I agreed with him, but I also work in real-time systems, and I do try to adhere to Rule #2. Actually, my rule is really "First you make it right, then you make it fast." -- /************************************************************************/ /* Sharon Foster....First Generation Trekkie * Internet: */ /* "So many books, so little time!" * foster@gdc.portal.com */ /***** These are my own Biased Personal Opinions and no one else's! *****/