Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!princeton!pucc!EGNILGES
From: EGNILGES@pucc.Princeton.EDU (Ed Nilges)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <12212@pucc.Princeton.EDU>
Date: 8 Jan 91 15:54:32 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <1047@gistdev.gist.com> <15809.278a0d04@levels.sait.edu.au>
Reply-To: EGNILGES@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 24
Disclaimer: Author bears full responsibility for contents of this article

In article <15809.278a0d04@levels.sait.edu.au>, xtbjh@levels.sait.edu.au writes:

>
>I agree strongly that software is an engineering discipline.  Any program
>is a trade off between many competing forces, including correctness,
>reliability, reusability, maintainability as well as speed, memory, disk etc.

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 know that in the so-called real world "today is more important than
correct."  Okay, ship with minor bugs if your customer says ship (and
buy malpractice insurance.)  But just as Richard Slomka, in NO NONSENSE
MANAGEMENT says that the fact that "the numbers" aren't perfect means
you should not stop your search for correct numbers, the fact that
real software almost always has some bugs does not mean that bug removal
is not an honorable calling, and that correctness is not the goal.