pausable explanation for the Document Series

[Bound, Jim]

This sounds like really good input to our process draft I suggest too
and instead of just having Be conservative what you send but liberal in
what your receive how about adding what Bob Hinden just said about
products and bugs and add that to our "core" values and it would mean a
lot more and get a lot more done.

/jim

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko at piuha.net] 
> Sent: Friday, June 06, 2003 1:57 AM
> To: Bob Hinden
> Cc: problem-statement at alvestrand.no
> Subject: Re: pausable explanation for the Document Series
> 
> 
> Bob Hinden wrote:
> 
> >> The more-core problem is industry running on protocols with design
> >> flaws and protocol bugs, which cannot be fixed because of the 
> >> installed base.
> >>
> >> If PS was perfect, this would not be a serious problem. 
> But it isn't 
> >> so.
> > 
> > 
> > First versions of anything are never perfect.  This is true for 
> > products
> > and standards.  As long as we try to solve the problem by 
> trying to make 
> > the first version perfect we will fail.  It only delays the first 
> > version and causes it to miss the market need.  The only 
> solution I know 
> > of is to do new versions.  This seems to work well in industry.
> > 
> > Perfection doesn't work.  Shipping products and getting bug reports 
> > works.
> 
> Agree 100%. Waterfall development vs. incremental 
> development. Serious debates early on in the project how all 
> possible features "must" be supported. Claims that engineers 
> would not make the mistakes they usually do, if they had just 
> done more "planning" or "design". Introduction of reviews, so 
> that more problems can be caught. Claims that the product we 
> are making is soooo important that we can not possibly have 
> any bugs or missing features in it. In the end, key success 
> factors for the project are missed, because no one bothered 
> to try out how the thing would work out in real usage. Or 
> competition is on its improvement cycle 17 when your first 
> buggy release comes out. Or you run out of money. Finally, 
> the management blames the engineers for bad quality.
> 
> I've been there in the distant past, but I know better now.
> But I'm alarmed that the above sounds very much like the 
> discussions we're having here.
> 
> A few observations on what this might mean for
> the IETF:
> 
> - It really is essential to get real usage, not just
>    more reviews or interop tests. So *some* amount of
>    industry adoption early on is required.
> 
> - Having to "fix" a standard (e.g. deprecate site-locals)
>    is not a sign of bad early specifications, its a sign
>    of being able to learn and adopt.
> 
> - While we normally don't like to compromise on things
>    like quality, security, scalability, we have to learn
>    to do things in pieces better. And when we are already
>    doing things in small pieces, we need to have a better
>    view of the full architecture/roadmap early on.
> 
> - This doesn't necessarily mean that we have to put out
>    more PS RFCs with a lower quality. We could keep
>    ahead of the industry's exaggeration of PS status
>    value by introducing a new document level lower in
>    chain.
> 
> --Jari
> 
> 
>