Xref: utzoo comp.sw.components:359 comp.software-eng:2201
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Schedule and budget are secondary
Message-ID: <1989Oct18.201225.3330@world.std.com>
Date: 18 Oct 89 20:12:25 GMT
References: <16168@vail.ICO.ISC.COM> <6693@hubcap.clemson.edu> <3807@rtech.rtech.com> <16202@vail.ICO.ISC.COM> <3829@rtech.rtech.com>
Reply-To: madd@world.UUCP (jim frost)
Organization: The World
Lines: 21

In article <3829@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes:
>In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>>You have to make the software a little hardier than it should need to be
>>in order to survive what it will be put through.
[...]
>Well your main point remains valid, i.e. that one needs to think about 
>future maintenance/enhancement when coding something.

Yes; the technique I've used is to error-check arguments everywhere
that performance isn't ABSOLUTELY necessary, even in distributed code.

This costs some performance but improves the initial quality and
future maintainability.  During development it catches early
programming errors, saving debug time.  Sometimes it saves a LOT of
debug time.  During maintenance it provides known points of failure
which can be used in tracking reported bugs and drops the likelihood
that low-quality programmers will use functions incorrectly.

jim frost
software tool & die
madd@std.com