Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!microsoft!petergo
From: petergo@microsoft.UUCP (Peter GOLDE)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <6@microsoft.UUCP>
Date: 13 Jan 91 00:16:29 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <1047@gistdev.gist.com> <15809.278a0d04@levels.sait.edu.au> <12212@pucc.Princeton.EDU>
Reply-To: petergo@microsoft.UUCP (Peter GOLDE)
Organization: Microsoft Corp., Redmond WA
Lines: 27

In article <12212@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes:
>In article <15809.278a0d04@levels.sait.edu.au>, xtbjh@levels.sait.edu.au writes:
>
>Hmph?  I am not sure that you can "trade off" various levels of
>correctness.  A software system is either correct, or else it isn't.
>Also, correctness UNDERLIES reliability, reusability, maintainability
>and even speed: an incorrect program is ipso facto unreliable, com-
>petent programmers are loth to reuse incorrect software, and when you
>maintain such software your first job is to make it correct...only
>then should you make changes to it.  As to speed, you shouldn't even
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>worry about it until you have a correct program, and in my experience
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>minor uncorrected bugs can in certain circumstances be a drag on speed.

I find statements like this bizarre, especially in a group devoted
to software engineering.  Essentially you are saying that one of the
key requirements of your software (speed) should be completely ignored
until after implementation is complete.  This is contrary to virtually
all software engineering advice that I have ever heard.  You have to
consider ALL the requirements, including performance, during the design
and implementation of software.  In my experience, hacking in either
performance or correctness "after the fact" is very difficult.

--Peter Golde
Microsoft Corp.
petergo%microsoft@uunet.uu.net