Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!bacchus!matt
From: matt@bacchus.esa.oz (Matthew Atterbury)
Newsgroups: comp.software-eng
Subject: Re: Retrospective Forecasting
Message-ID: <607@bacchus.esa.oz>
Date: 1 Mar 90 22:06:21 GMT
References: <37392@iuvax.cs.indiana.edu> <2262@mrsvr.UUCP>
Organization: none
Lines: 33
Reply-To:

In article <2262@mrsvr.UUCP> mcilree@mrsvr.UUCP (Robert McIlree) writes:
>From article <37392@iuvax.cs.indiana.edu>, by smith@iuvax.cs.indiana.edu (John W. Smith):
>> 	The second mistake we make is to remember the time it took to
>> FIX the problem, but not the time it took to FIND it.  [...]
>>                           :
>
>If you have an established design methodology, and adhere to it closely,
>you could reduce the time spent in finding the problem by reviewing
>where the defect occurred in the process.   [...]
>                            :
>Bob McIlree

Yeah Team!
            IMHO the most useful/important reason/effect of a good design
[using an established (and understood) design *method*] is that the coder,
when confronted with a defect, can often say:

    Hmmm, this is being done wrongly ...
          this can ONLY be done in this module ...
          this can ONLY be done by these [few] routines ...
          this particular defect sounds like this routine ...
          bingo! that must be it!

    All this WITHOUT looking at any code.

Obviously, this requires a very good knowledge of the design and a
good understanding of the code [less important since often the defect
is a design error] - a luxury not every one can have.
-- 
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz.au]   Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz.au            "klaatu barada nikto"
ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET  "life? don't talk to me about life!"