Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!mrsvr.UUCP
From: mcilree@mrsvr.UUCP (Robert McIlree)
Newsgroups: comp.software-eng
Subject: Re: Retrospective Forecasting
Message-ID: <2262@mrsvr.UUCP>
Date: 28 Feb 90 17:23:54 GMT
References: <37392@iuvax.cs.indiana.edu>
Sender: news@mrsvr.UUCP
Lines: 48

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.  It takes half
> an hour to change the number and recompile the program.  That's what
> your staff will remember.  They DON'T remember the two weeks it took
> to figure out that it was that particular number which was causing the
> problem.

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. I use the term defect here
as opposed to bugs because a substantial number of problems with
systems occur in the requirements, architecture, and functional
design phases. The implementation of defects in code (bugs) are the
manifestation. Serious defects propagate throughout the entire
design cycle, such that it's no longer an issue of fixing bugs in code.
Rather, the issue centers around should the system have been designed
and built in the first place, complete reorientation of the project,
etc.

My main point in this regard is, assuming proper systems engineering
and structured design techniques, the concentration of effort on
fixing bugs in code is moot. The effort should focus on the design
or requirements defects that spawned the problem in the first place.

> 	It could be that the kind of people who are attracted to a
> fast-moving and ever-changing environment such as ours are evolutionarily 
> selected to NOT have a historical perspective.  But if we're trying to
> manage, hence control, our environment, it is a very valuable tool
> that we could make much better use of.  Although the examples I've
> given pertain specifically to management rather than forecasting, the
> basic ideas are no less true.

Management and forecasting aren't mutually exclusive. In order to
properly forecast, you need historical data. To get that data, it
must be collected, crunched, and represented in some form that
non-technical types can understand and make use of. To insure that
you get the data and act upon the outcomes, you must manage that
process.

I agree wholehartedly that a historical perspective helps greatly
in controlling quality, and fine-tuning of development processes.
It's a sizeable effort to set this up, and the pay-offs are not
short-term, but in places where I've seen it practiced, well worth
the resources and effort long-term.


Bob McIlree