Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!microsoft!stevebr
From: stevebr@microsoft.UUCP (Steve BRANDLI)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <70105@microsoft.UUCP>
Date: 19 Jan 91 00:07:42 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> <price.663815908@helios> <70101@microsoft.UUCP>
Reply-To: stevebr@microsoft.UUCP (Steve BRANDLI)
Organization: Microsoft Corp., Redmond WA
Lines: 40

In article <70101@microsoft.UUCP> petergo@microsoft.UUCP (Peter GOLDE) writes:
>However, this wasn't really the point I was addressing in my 
>original post.  I was responding to a claim that one should not
>consider efficiency until one is done writing a _program_.  Since
>a program is likely to take at least a year to complete, this involves
>going back to code not considered for a very long time, possibly
>written by someone else, and speeding it up, without breaking any
>other code in the program at the same time.  Since most real speedups
>are obtained by changing data structures, not by minor code tweaks, this
>results in the all-too-common nightmare of trying to find all the
>places that a given change impacts.  At best, you have to retest the
>whole program; at worst, you can't make any changes at all because
>you can't find all the places that depend on it.  Abstract data
>types and object-oriented techniques can partially alleviate these
>problems, but it is better not to have them at all.
>
>This is the reason that I consider statements like "I won't worry
>about efficiency now, I'll speed it up later" dangerous and 
>unprofessional.  If speed (or space -- even harder to address after
>the fact) is important then it is important enough to worry about
>from the beginning.

I'm sure there are software projects that are understood well enough that
you know which sections of the code are worth optimizing.  But I haven't
worked on one (of decent size) yet where this was obvious.

I think a good developer can/should write relatively efficient code from a
local viewpoint, but attempting to be globally optimal early in the
development cycle can result in time spent in the wrong areas.  So, in
my opinion:

1) Spec., design, etc.

2) Write the program (or separatable section)

3) Determine where extra work will provide a benefit relative to the cost

4) Perform that work

/Steve (uunet!microsoft!stevebr)