Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!hrc!calvin-klein!gibsong
From: gibsong@calvin-klein.UUCP (Greggo)
Newsgroups: comp.software-eng
Subject: Re: The Errors of TEX
Keywords: testing debugging structured-programming OOD
Message-ID: <46357e8c.14c3d@calvin-klein.UUCP>
Date: 13 Oct 89 20:52:27 GMT
References: <2402@munnari.oz.au>
Organization: gte
Lines: 39

In article <2402@munnari.oz.au>, sharam@munnari.oz.au (Sharam Hekmatpour) writes
(among other things):
> 
> The worst aspect of Big Bang is that it gives you no time to reconsider
> your design. When it comes to testing, a whole army of design faults hit
> you dead. You'll have no idea where to begin. The bugs are so many and
> so interdependent that you don't know what's causing what. From this point
> on it's all hacking. This is where false confidence gets you.
> 
> Systematic testing, however, gives you justified confidence. When it comes
> to integration, at least you have a good idea how reliable each component
> is. There will be less errors and these can be quickly located and corrected.
> 
> [ and from earlier in the posting: ]
>
> For my own program, I tested most modules first in isolation and then during
> incremental integration. Of the 2 years that I spent on this program about 6
> months of it was solid, systematic testing. Had I used Knuth's approach
> I could have perhaps cut down this time to 3 months, but I doubt very
> much if the whole thing would have worked in the end.
> 

It sounds to me as if your method and Knuth's achieve much the same end, but
that your "redesign of the system" occurs little by little as you test each
piece, find a problem, correct the code, retest, etc.  Whereas Knuth used
more of a strict waterfall model of "design all, then test all, then redesign
all", your method is more iterative: "design a little, test a little, redesign
that, design some more, ...".  That's why your estimate of testing with
Knuth's method was 1/2 of what you actually spent; you were indeed testing 2
systems (one original, one redesigned) instead of one.

I personally prefer the iterative method, mainly because my threshold of doing
the same activity (design, test, whatever) for a long time (several months)
is much lower than if I mix up my work and keep some variety.  Note, however,
that to meet time-to-market and competitive demands (as discussed in other
postings), the iterative method can mean longer initial development intervals
(although with cheaper maintenance), so many companies still stick to the
waterfall model to get a product out and make a little moola (at the expense
of greater maintenance expense later).