Why small code increments are good if tinkering is expected
Stefano Mazzochi (via Sam Ruby) states the case eloquently for small increments of code in an open source project.
"The hardest and best the code is, the more harm it creates to the
community; this is because people will rather use the software rather
than extend it. Normally, if more than one blackboxware submission is
donated, the community will ask for a complete refactoring. (see
Xerces2)"
This is a great insight. Every time this has happened on a project that I am working, the incentive to stay away from that code has been high. When a large chunk of code drops in (I would argue even if it is relatively easy to understand) it creates a large barrier to understanding and thus to extension. Now this may be a virtue if you don't want extension:), but if the expectation is that things will be changing over time then incrementalism is a good friend.
"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."
This is another key insight. Architecture as an emergent property rather than a static set of constraints or characteristics. This is particularly important where adaptation is more important than optimization (see Jim Highsmith here). I like that! Architecture should follow design whenever possible to allow the system to evolve rapidly to where it wants to go. Build it often, build it to run, make sure you can always go back to what ran previously.
10:05:46 AM 
|
