Friday, December 30, 2016

SOLID principles and self reflection on over designing software

Rob Ashton, someone on the internet who codes, has opinions on the SOLID principles that resonate with the kind of decision making we are taught in school but isn't practical for the real world. I'm not debating whether or not there are measurable benefits to these changes, but the complexity added to the code is the unmeasured cost when you design in the ivory tower.

I've definitely made this mistake in over architecting, and so has Rob. He quotes a fictional self that resonates a little too close home:

What if somebody at some point wants to change this so they can have another behaviour for this value, I'd better use the strategy pattern here instead of this switch statement, but oh my word now I've done that what if somebody wants to use this code from some other system than this one, I'd better stick a command system in front of this and use double dispatch for handling them - but wait, what if other code needs to react from this and do something else, I'd better raise a pile of events, but what if those aren't enough I'd better make sure I split all this behaviours out into their own interfaces so they can be overridden and...
http://codeofrob.com/entries/my-relationship-with-solid---the-big-o.html

Everything in there I've done. Not quite in that order (I have a habit of implementing interfaces for everything)  but event handlers, command pattern, it so often ends up useless in typical LOB business software that I've been writing. You figure if it would matter anywhere it would be here, but not the case. Certainly overkill if we worked on one-off customer work. YAGNI and KISS are very applicable in one off projects or services engagements. Even in more recent engagements with software companies, "wiring" and "piping" can be extended after-the-fact to support your nonfunctional requirements (assuming you have decent test suites).

TL;DR: Don't be an architecture astronaut.


No comments:

Post a Comment