The Imposition Of Pattern

Dr Stuart Woolley
Published in
5 min readNov 18, 2023


Order isn’t necessarily the best thing in software engineering.

“Image generated using OpenAI’s DALL·E.”

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.


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 well, and that way was madness and a potential coming of a kind of dark future of “Newspeak software engineering”.

Fortunately, it didn’t last.
But I digress, perhaps this is a future article all of its own.

When I wax lyrical about the terrible effects that enforced obfuscated and over-engineered process has on the Grand Game of Software Engineering, I often think of a sinister pattern³ being enforced, in a very draconian fashion, upon our own beautiful world.

By building up a morass of rules and regulations and by the continual enforcement of rigid doctrine the spark of creativity and imagination is snuffed out, dismissed, never to return.

Where we once picked up a problem, threw in our lot, and got down to work thrashing out a design, a simple implementation plan, and getting some source code down we now have to embark without a plan, constantly change…



Dr Stuart Woolley

Worries about the future. Way too involved with software. Likes coffee, maths, and . Would prefer to be in academia. SpaceX, Twitter, and Overwatch fan.