Is premature architectural abstraction the new premature optimisation?
There seems to be a certain breed of lead developer who simply can’t help themselves when faced with a new project. For them the reward of knowing that’ve you’ve built a logical, well considered system simply isn’t sufficient. Perhaps they start off small, with just a vague outline of a few objects and an idea of the sort of data they’ll be operating on, but this soon falls by the wayside – they’ve moved on to bigger stuff, all in service of their goal to create a pristine hierarchy of crystalline class structures, each of which bask in the glow of their inner perfection. For they alone have created…
THE ONE TRUE ARCHITECTURE
Maybe it’s just a phase all developers go through, before the crushing reality of commercial considerations comes crashing down around them? After all, such work is tremendously mentally invigorating, so you could be excused for doing it instead of getting bogged down trying to create a system that merely solves the problem at hand. I mean, the budget is just a suggestion isn’t it? And just think of all the other projects that’ll be able to make use of THE ARCHITECTURE once it’s been completed – think of all the time you’ll save in the long run. Although it’ll probably take a few projects before it’s really complete.
Irrespective, if left un-checked such behaviour can have somewhat catastrophic effects in the real-world, both commercially and on the morale of any unfortunate souls who end up having to work on such a system. (Because you see, such systems are rarely documented – code is self documenting after all – didn’t you know?)
…and some poor bugger ends up having the kludge an entire hierarchy to make things work as required.
It’s either naivety or over-confidence verging on arrogance to believe that the set of abstractions you envisage at the start of a project are going to have a significant degree of overlap with what it transpired you really needed as the real world requirements inevitably shifted during development. Even the most perfect architecture will take a hit at the point the requirements for the system in question change fractionally.
You can generally tell when you’re dealing with such a developer, as everything they do involves attempting to build some epic “one size fits all” system, rather than actually attempting to solve the specific problem at hand.
Perhaps I’m just a hopeless old romantic, but solving the problem first and then attempting to abstract back to a more generic solution would seem to be a considerably more sensible approach for all but the most obvious of architectural decisions.
If you’re not solving the problem In the most minimal way possible, all you’re doing is creating problems for those who follow in your footsteps.
If you notice these traits (yes, that was intentional – aren’t I clever) in yourself, here’s some practical tips…
- Keep things modular
The most flexible way of solving a problem is to break it down into pieces, write the code to address each of those pieces and use the most minimal framework possible to join each of the pieces together. If you’re spending a lot of time not in direct service of this goal, something is wrong. - Keep things simple
You probably don’t really need that nested set of ternary operators, do you? I mean, clearly you’re super duper clever because you can unpack the logic in your head in an instant, but everyone else just thinks your code is needlessly obfuscated. - Maintenance is all that matters
As a general rule of thumb, I’d recommend only trying to write code that you’d understand if you were a bit drunk. Use whatever language-specific class method/function documentation you can (hopefully your IDE will make use of these to prevent you from making a fool of yourself) and add helpful little comments where apt to guide your drunk self.
Anyway, I’ll stop now – there’s a XXX that’s simply begging to be written.
