The Great Lies of Software Architecture

I was staggering through my RSS feeds tonight, wondering how many more blatant insanities our elected officials would be able to unleash on us this week, when Jeremy Miller's blog post tonight reminded me that we've no further to look than our own trade.  Take a minute and go read it - it's a narrowly-targeted rant, and a quick read:

Separate Assemblies != Loose Coupling

I agree with Jeremy on all counts, but I'll add a couple more logs on the fire.  The bit about "can you change one thing without messing up others" struck a nerve, but I've seen multiple architectures recently that seem to be even worse than this.

It's bad enough, after all, to inadvertently create a fragile architecture stack such that you "may" have to propagate change from assembly to assembly, but I'm seeing a lot of solution stacks where the normal development use case is to have to make changes in a half-dozen or more assemblies every time the smallest change is required.

This anti-pattern may be a function of jar-envy among J2EE-coveting .Net developers, or it may be the product of an unfortunate accident with a rubber band, a particle accelerator, and a Gang-of-Four book (to paraphrase Douglas Adams).  In any event, the problem results in a solution with at least twice the number of projects than is really necessary.  Maintenance and enhancement of these solutions is a nightmare, because every little change you make has to be propagated up and down this immense stack of useless monuments to architectural overkill.

No civil engineer in the world would be able to build a structure this way.  After the third or fourth on-ramp that doesn't go anywhere, someone's going to start asking questions, but sadly, nobody asks why we create interface projects when we know damned well that there's only ever going to be one concrete class to use it.

And then there's "someday".

"Someday" may be responsible for more useless scaffolding and mass than any other single word in software.  Take a page from Agile and build only what you need.  On top of that, if you throw a bunch of stuff in another assembly, but you can't satisfy the separation principles that Jeremy talks about, then guess what?  You're not really doing "someday" any favors.  And if all else fails, just remember what CCR said about tomorrow.

That's probably about enough for one rant.  Next time, maybe I'll share a few thoughts on spaghetti-SOA.