Extreme Programming had this idea of doing "the simplest thing that could possibly work". Don't get hung up on lots of architecture or design; make something simple that works. But of course, that doesn't work for long - the requirements get more sophisticated, and the simplest thing no longer works. Then you have to refactor/redesign/rearchitect. And that's OK, <i>because now you know which direction to do it in</i>. But don't do more than you need for now, because you don't know which direction to do "more" in.<p>Design up front for reuse is, in essence, premature optimization.
Interesting to think that complexity can be a result of trying to do proper software architecture. It occurs to me that the way software is typically built probably approaches the problem of complexity in software architecture from the wrong end. We try to build software systems that minimize complexity, have predictable behavior and operate under controlled conditions. Most software has extremely low tolerances for aberrant behavior.<p>Looking at biological systems though, that is the opposite of how reliable systems are constructed. If we design from the assumption of failure and runaway complexity, with watchdog and recovery processes, and using emergent behavior from small discrete components to obtain large-scale results, then we can build software components that are much better able to recover from unexpected interaction and produce more reliable systems. It seems to me that this is what the theory should be. I just have no idea how to do that in the real world when building a web app, aside from recycling server processes every now and then.
The article references a paper from 1980 called "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". I just skimmed it - incredible insights that continue to be relevant.
The current trend in software architecture is called "Sacrificial Architecture" by Fowler: <a href="http://martinfowler.com/bliki/SacrificialArchitecture.html" rel="nofollow">http://martinfowler.com/bliki/SacrificialArchitecture.html</a> .<p>You don't even try to "evolve" software but periodically rewrite it which "solves" the "Paradoxes of Software Architecture" in one fell swoop. Disposable instead of durable software.
I have been having similar thoughts recently. Someone we work with was demonstrating some module he had built. My boss asked if he could make it do something. He explained he could make it do that, but didn't want to as it would break the loose coupling he had developed. Loose coupling is nice to have but surely functionality should come first if it is needed.