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

Reply via email to