The Imposition Of Pattern
Order isn’t necessarily the best thing in software engineering.
A long, long time ago I was introduced to the Chronicles of Amber, a series of novels by Roger Zelazny¹ and though the lore and stories based on that world are way more than can be even superfluously dipped into with words of this one paragraph, there is a fundamental concept that’s stayed with me and that’s the universal balance between order and chaos, or as referred to in the books, the Pattern and the Logrus.
Briefly, the Pattern represents unchanging order² and the Logrus constantly changing chaos.
Aside:
I’d just like to point out here (as this point was originally a footnote but the footnote crew kicked it out for being way too long) that I’m not in any way talking about software patterns.
If anything, software patterns were very much part of the problem in that yes, we know they exist, yes we often do code in that way, and yes they’re a useful tool to describe program construction.
But, we should most definitely not adopt them, promote them, and make them our absolute rulers.
If we are forced to design our code only in terms of patterns then go on to rigidly code using patterns we constrain ourselves. The world of telecommunications did this most tragically, I remember it…
