The "late surprise" problem

Henrik Levkowetz henrik at riesling.local.levkowetz.com
Tue Mar 25 20:31:45 CET 2003


On Tue, 25 Mar 2003 00:33:41 -0500, Keith Moore <moore at cs.utk.edu> wrote:
> 
> > rather than debating the problem, I decided to follow the time-honored 
> > principle of "when in doubt, do something", and created the 
> > "solutions at alvestrand.no" list.
> 
> Sigh.  Even if this is not official, I fear that this will distract 
> valuable energy from the problem determination effort.
> 
> I can understand the occasional foray into potential solution space.  
> But why is it that we cannot take the time to gain a comprehensive 
> understanding of our problem before we start investing much more energy 
> on solutions?
> 
> Maybe this is IETF's primary problem?
> 

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. So why this
rather heavy reluctance within the IETF to look at possible solutions
until the problem statement is polished and gilded?

More often than not, starting to look at possible solutions while you
are defining the problem gives insights that can be fed back into the
problem description and make both problem understanding and solutions
better. That doesn't mean that you should arbitrarily mix the two up -
but then Harald's initiative in creating the solutions list helps with
exactly this, keeping the two distinct.

The only reason I can see to not look at solutions until the problem
description is finished is that you think there may not be a problem
there at all -- i.e. you want to be assured that it's not all a wild
goose chase. So do we believe that we have no problem here?

	Henrik

-- 
  If at first you don't succeed, skydiving is not for you.


More information about the Problem-statement mailing list