Hey folks, TL;DR ---- Small steps! Less friction! Lazy consensus! Reversible change! Meritocracyyyyyyyyyyyyyyyyy! YAY :-D
History ---- "Use small reversible steps" is a powerful idea when evolving things, like when evolving a software architecture. It's an idea that was made popular @ apache by Stefano. Since the idea seems to be drifting to the back of our minds a bit lately, I thought I'd bring it to the front again [1,4]: It's exactly like thermodynamics, where a infinite number of small reversible steps is more efficient than a small number of big but not-reversible steps. The good old Software Engineering practices they teach you in college are bullshit: making architecture decisions without continous reversibility is expensive because design constraints change too much. Those who want to apply hardware engineering practices miserably fail. Open source is here to prove that such a "messy" way to do code is actually the only one that works and scales. Thankfully, 'incrementalism' is much more prevalent in IT now than it was a decade ago :-). Perhaps not as well understood, but, it is also a very powerful approach to shaping communities and community behavior [2]. Among other things, gaining consensus gets easier the smaller the increment, to the point that you can get away with lazy consensus for the smallest of steps, which is indeed very efficient. Erosion vs destruction ---- I do suspect radical goals such as deconstructing the incubator [3] are worthwhile to pursue. The deconstruction of jakarta followed (after much deliberation) an incremental approach with many small and reversible steps. That was the right choice then, and I'm confident it is the right approach here. I.e. deconstruction by erosion instead of by destruction. By contrast, heavyweight big-bang discussion full of rhetoric where conversation is cast into argument with those 'for' and 'against' is of very limited value. Turning sets of ideas into a 'platform' that you must buy in to (or not) is worse. It divides a community that does not need to be divided, and it impedes consensus much more than needed. We won't get far that way. I'm glad I missed a week full of such e-mail while I was on holiday :-). I shall continue to try to steer clear of it! (hug), Leo [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200010.mbox/%3c39fad0b5.2d3f4...@apache.org%3E [2] http://psteitz.blogspot.com/2011/08/engineering-emergent-behavior.html [3] http://wiki.apache.org/incubator/IncubatorDeconstructionProposal [4] that took ages to find btw. I think it's the first reference on a public list to entropy concepts in IT, at least around here? --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org