On Fri, Sep 26, 2014 at 5:34 AM, Andrei POPESCU <andreimpope...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMnOZHxKY6asGCo4k0OB9257zOsRuOcrJg=kpddbgu...@mail.gmail.com
