Re: Effectively criticizing decisions you disagree with in Debian
On Fri, Sep 26, 2014 at 5:34 AM, Andrei POPESCU
<andreimpopescu@gmail.com> wrote:
> On Jo, 25 sep 14, 21:27:30, Joel Rees wrote:
>>
>> There is always that possibility. It's one of the reasons for the old
>> adage, "If it ain't broke, don't fix it."
>
> http://en.wikipedia.org/wiki/Kaizen
Sigh.
Andrei, I would be the last person on earth to tell anyone not to use
step-wise refinement when it's appropriate, which is most of the time.
Big steps, by comparison, bear some similarities to fiat politics. Big
steps tend to be destructive and counter-productive, over-all, even
though marketing departments seem to be generally enamored with the
the "next big thing".
But big steps are also sometimes appropriate.
Change for the sake of change is even appropriate, to avoid stagnation.
All of which stand in opposition to the adage you quoted without the
original context. This is true.
That adage expresses a principle which also has an appropriate
application, just as step-wise refinement, big steps, and arbitrary
change have appropriate times and contexts to be used.
A big part of engineering is knowing when, where, and how to apply which.
Complexity (which I also mentioned briefly in the parts you removed)
is one of the factors which should be used to select one's approach to
change. Functional and parameter entanglement are other factors, which
should be considered separately from complexity.
In the context you removed (in your effort not to clutter the
conversation with cruft, I believe) Lee was talking about the
possibility that change might make things worse, I think, and I was
acknowledging that possibility by mentioning the adage.
He also mentioned the conflation of different kinds and expressions of
complexity, which I tried to unpack a little.
(Complexity is a topic with which I am somewhat familiar. I sometimes
tend to rant about it, but people complain about links to such things
these days. I think you can find my blogs if you are interested, but I
should warn you, I haven't really been satisfied with any of the rants
I have written on the subject yet. It's a difficult topic without some
context of reference.
I suppose I should give more time to ranting about change, if I'm
going to rant about such things in public.)
It appears to me that one of the questions which are causing so much
back-and-forth here is whether the topics of complexity were
considered in the recent selection of the new init process package.
I've read the developers' conversations until my eyes crossed, and,
frankly, it looks like complexity has been treated with hand-waving by
all. It is as if perceived complexity, which is something of a matter
of opinion, were the only kind of complexity necessary to consider.
I wanted to find some real treatment of the engineer principles of
complexity in the conversation, and I have yet to find it. If I
express my observations of what I have seen when the conversation
approaches the questions, well, it has been said before. Some,
including myself, have gotten so frustrated about it as to go over the
top in our descriptions. Repeating it here would not likely help the
conversation.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Reply to: