The "late surprise" problem

[Henrik Levkowetz]

On Tue, 25 Mar 2003 23:07:07 -0500, Keith Moore <moore at cs.utk.edu> wrote:
> > Hmm. In software development, it has been recognized for 8 years or so
> > that the waterfall model gives far to long development cycles --
> > iterative development lets you work on specification, design,
> > implementation and testing in parallel, giving faster results, better
> > throughput, better understanding and better solutions.
> 
> software development is not representative of engineering as a whole, 

true, but that shouldn't keep us from considering what we've learnt there

> and it's not clear that the lesson of software development is more 
> applicable to protocol engineering than the lessons from other forms of 
> engineering.  also, the lessons you cite from software development are 
> heavily-biased toward the fast-changing markets we were seeing a few 
> years ago; they are not necessarily applicable to a more stable 
> software market.

quite incorrect in my experience. I've applied and experienced iterative
development mainly in embedded computing with product lifetimes of 10 -
15 years, and the technique is still hugely appropriate and successful
there

> iterative development can work well when you have enough knowledge, 
> experience, and intuition about the problem that your first prototype 
> is within epsilon of the final solution

This I believe to be incorrect too. It is just as useful when your
knowledge of the problem domain is such that your first attempt at a
solution will be far from optimal. Sometimes it is difficult to gain a
complete understanding of the problem without attempting a solution and
understanding how it works.

> and when you have the luxury 
> of doing testing before actually having to use the product.  neither of 
> these conditions seems to hold here.

The *major* reason for iterative development being inappropriate in some
diciplines is that the cost and time of implementation overshadows the
cost and time of design. Trying to iteratively build the Golden Gate
bridge comes to mind as an example.  But even in this case, one might
build models and do stress and cost calculations on more than one design
in parallel, before deciding on the final one to implement.

If we can parallelize the process somewhat, in this workgroup as well as
in other IETF workgroups, it might make our output more timely.

	Henrik