Re: [Tools-discuss] Time in States on Datatracker

[John C Klensin <[e-mail]>]

Lars,

--On Thursday, June 16, 2022 12:43 +0300 Lars Eggert
<[e-mail]> wrote:

> Hi,
> 
> On 2022-6-16, at 11:39, John C Klensin <[e-mail]>
> wrote:
>> More broadly, would it be useful to ask that every change that
>> might result in a reduction in functionality (or in obvious
>> access to information) be announced to the community in
>> advance with an opportunity for comment rather than deployed,
>> effectively seeing if anyone screaming in agony?
> 
> I think this would really slow down development of the tools.
> I much prefer an approach where we let the volunteers improve
> things, and if stuff gets inadvertently broken, it gets fixed
> again. (A fix for this one is queued up already.)

Disclaimer with apologies to those who know this already: Early
in the programming part of my career, I worked on a fewprojects
that put very high emphasis on software quality.  One was
logically adjacent to some of the Project Apollo space mission
work and I frequently heard quality guidelines like "get it
wrong and people will die and die spectacularly".  Two or three
others involved work that needed to be very sensitive to the
costs of mistakes, especially design mistakes, to users.  All of
them made a distinction between design, which had to be right or
nothing else was possibly and implementation, which had to be
done carefully but where that was an understanding that bugs
might appear.  If they did, there needed to be a plan (sometimes
starting with design) to minimize their impact and get fixes
deployed quickly.   Perhaps those experiences, and the
consequent education, affected me too much.  I have never gotten
over it, and it affects my view of a number of things.

That said, I think a decision to do formal implementation review
and testing by QA experts would be a bad tradeoff for the reason
you suggest.  However, it seems to me that a decision to reduce
or significantly change functionality of a mostly working tool
is a design decision, not merely an implementation one, and
something that could (and probably should) be checked
pre-implementation.  If nothing else, getting something right
the first time may consume less time and resources overall than
doing it one way, listening to the cries of anguish (which
themselves take time), and then going back to do it another way.

Rolling out a new tool with no functionality --not an update or
replacement that has been in use and that people are used to--
might well involve an entirely different set of tradeoffs,
including arguments for not spending a lot of time on design
that would need to be revised once people see what they thought
they were asking for.

The tradeoffs are obviously more complicated than that and I
don't mean to oversimplify them, but I am reminded that adages
about "fast, good, or cheap" used to be quoted often around the
IETF.  Maybe I'm the only one (and it would be a huge
exaggeration in this particular case), but choosing the first
and third does not seem to me to be the right choice here. 

>>  If nothing
>> else and with respect to Lars (and I generally agree with his
>> design taste), making design decisions based on "downward
>> pressure" is a little bit more top-down than the IETF is
>> supposed to operate.  That is especially problematic when the
>> pressure and decisions are invisible to the community until
>> after the fact.
> 
> Just to be clear, I'm not wearing any leadership hat here. I'm
> a tools volunteer that is trying to make a tool work better.

Thanks.  That was not clear from the message to which I was
responding.

best,
   john