James Hague: "But all the little bits of complexity, all those cases where indecision caused one option that probably wasn't even needed in the first place to be replaced by two options, all those bad choices that were never remedied for fear of someone somewhere having to change a line of code... They slowly accreted until it all got out of control, and we got comfortable with systems that were impossible to understand."
Counterpoint by John Cook: "Some of the growth in complexity is understandable. It's a lot easier to maintain an orthogonal design when your software isn't being used. Software that gets used becomes less orthogonal and develops diagonal shortcuts." If there's ever been a system in
dire need of a complete redesign, it's UNIX and its derivatives. A mess doesn't even begin to describe it (for those already frantically reaching for the comment button, note that this applies to other systems as well).
Member since:
2007-02-18
I once explained this insidious habit of calling stacking layer upon layer "fixing things" (instead of actually fixing the root issues) "
The reason why this layer stacking happens (developers like to call it "abstraction") is in the futile hope that if they can get everything to work on a standardized layer, they can then get on with the task of fixing everything underneath the layer without breaking people's setups.
That ends up not happening because 1) developers, whether open source or commercial, are fired up about the designing of a new layer, but that excitement dies soon after it's half finished 2) end user software can't keep up with the changes, whether it's the people making them, or the people using them not wanting to change 3) developers create competing standards which means no one wants to commit to a design that won't survive.
Layering is a necessary evil because no one wants to break everything, especially the developers.