Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!hoss!price From: price@helios.unl.edu (Chad Price) Newsgroups: comp.software-eng Subject: Re: Effect of execution-speed on reliability/testing Message-ID: Date: 14 Jan 91 01:18:28 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> <6@microsoft.UUCP> Sender: news@hoss.unl.edu (Network News Administer) Organization: University of Nebraska - Lincoln Lines: 58 petergo@microsoft.UUCP (Peter GOLDE) writes: >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 much criticism deleted. It seems that some gross assumptions about the original poster's meaning are being made here. Given that one has decided upon an algorithm which is 1) correct for the purpose, and 2) the most efficient that one can find; there are still many ways to code that algorithm. I agree that efficiency should not be considered until after coding is finished and a correct result is apparent (via testing ...). Then one should take the algorithm and analyze the method by which it is implemented and see if there are better ways to accomplish the same algorithm. Thus these steps seem the best way to approach the problem: 1) Find the best algorithm for the purpose 2) Code it in the most obviously simple and reliable way 3) If that works correctly, optimize the resultant code. This method does NOT imply that no prior thought has gone in to the question of efficiency and speed, only that the best algorithm can still be coded in different ways, some of which may be noticably faster than others. A case in point occured some years ago when I was working on a Pick system coding in Pick Basic, which has static arrays as well as dynamic (undimensioned) arrays which locate data based on delimiters embedded in the arrays. My initial coding of a problem prodced correct results, but slowly using the dynamic arrays. By dimensioning the arrays at compile time, the run-time of the program decreased by an order of magnitude, using the same algorithm. All that was changed was the way in which the data structure was declared (or not as the case turned out). chad price price@fergvax.unl.edu