Deviation and dilution
About half of the first paragraph in the ‘What Is a Design Pattern?’ section of Chapter 1 of the GoF book[GoF94] was given over to a description of what a design pattern is outside of software development. For programmers to grasp what the term meant, much more was necessary. This most famous book on design patterns was published so bereft of detail or nuance; no wonder patterns have been so misunderstood by so many for so long.
The writers introduced the term a few times but never presented it with its foundations. I believe this was a mistake, as different people interpreted the words differently over the years, and the critical aspects of Christopher Alexander’s work were diluted and lost in the excitement.
Because the GoF book[GoF94] only references implementation-level object-oriented design patterns, a problem arose in the way they were understood as a concept. Imagine a famous fantasy book referencing elves and dwarves, orcs and wizards. Imagine it became such common knowledge that people assumed certain traits of fantasy books before they even read a synopsis. The success of the GoF patterns had an unintended consequence, accidentally suggesting that design patterns don’t work outside of object-oriented design. It was a strange side-effect but a mildly damaging one for other programming paradigms. No true elf would write production code in a functional language such as Haskell. The GoF patterns’ success also caused the meaning of design patterns to stick to a specific abstraction level. Modular architecture and team development practices are sorcery and dark magic, and as such, they have nothing to do with the science of design patterns. Other books vehemently contradicted this narrowing1 of meaning, but their popularity was insufficient to overcome this common misunderstanding.
Being the most famous book on software design patterns, it set the meaning of design patterns for the whole industry. Now, we have a diluted term and a hard time finding the right words to describe the real thing.
The term ‘design pattern’ is now a buzzword for ideas or practices. You see it used as a prefix for collections of ideas. Instead of 114 tips on how to clean up your network resources, you might see a Network Resource Design Patterns Handbook. Instead of a book of collected best practices for recipe layout, you get Design Patterns of Cookbook Construction2. Non-pattern design pattern books dilute the meaning and leave the pure patterns books vying for shelf and mind space. Genuine design pattern books are crowded out by the better-performing, more marketable content. I don’t wish to devalue the content of the better-performing books, but I do want to acknowledge how they hurt the specificity of the term ‘design pattern’.
The sting has been taken out of the term, and that’s both good and bad. Some people think design patterns are awful, so a new book on a subject containing design patterns might decide to hide it to some extent, as it might put off potential readers. Wait, is this why I called this book Unresolved Forces?
The power has been taken out of the term, leaving us with a problem. How do you refer to outstanding design patterns that are pure and revelatory? What do we now call powerful, self-forming, and reinforcing patterns of interaction in a building space? The next term along is meme, which has itself been co-opted by GIFs and ‘Rickrolling’. These terms themselves are not very strongly reinforcing patterns that correct themselves back to their pure forms. Instead, they mutate happily into whatever they need to be. I should not be shocked, really. Survival is more important than some artificial arbitrary meaning that spawned the terms. Culture eats meaning as it turns idioms into traditions.
This leads to a concern. How can we collect and curate patterns without a name by which to reference them? How can software design patterns be coaxed into some well-formed collection? Well, they can’t. And shouldn’t.
What we wanted from design patterns was a collection of tools to share to help guide us and bring us together. But that language was stifling. Like object-oriented programming, it held us back because it became the lingua franca for design talk. The design space is limited when teams only use known patterns or, more importantly, whatever the lead architect was aware of or informed about in time.
Thankfully, as far as I know, these examples don’t exist.