@Robert_Best let me respond to your question, because there’s a larger context at play, in your interaction with David L. Hawk. He was a professor at NJIT, cross-appointed between architecture and management, so he knows the pattern language literature well, in the domain of built environments.
Christopher Alexander, the primary proponent of a pattern language approach, never used the term “anti-pattern”. That arose within the days of the History of Patterns, and may reflect a weak appreciation of pattern language as a whole.
A generally accepted definition of an Alexandrian pattern is as “a solution to a problem in context”. The difficulty comes when users forget about context. It’s like asking how fast an apple falls to the ground, and then forgetting to say that the context is that we’re on the moon.
So, I’ve been an advocate towards not using the idea of “anti-pattern”, but instead engaging in a discussion of the context in which a solution may or may not work. As an extreme example, Thalidomide is a drug that may be appropriate in the treatment of cancers and leprosy, but is not advised for use by women of child-bearing age. That doesn’t make its prescription an anti-pattern, it’s still a pattern in a specified context.
Here is an excerpt from David Ing, “Pattern Manual for Service Systems Thinking: A proposal for discussion”, Proceedings of the 2016 International PUARL Conference , cached at http://coevolving.com/commons/20161028-pattern-manual-for-service-systems-thinking
4.3.3. From anti-patterns to wayfaring
For built environments, a pattern can be described as “relatively more alive, or more dead” and “relatively stable, and self-sustaining – or it is relatively unstable and self-destroying”.
Each of these “dead” patterns is incapable of containing its own forces, and keeping them in balance. What happens then, is that these forces leak out, beyond the confines of the pattern where they occur, and start to infect the other patterns (Alexander, 1979, p. 127).
In the end, the whole system must collapse. The slight stress caused by the overflow of forces from these first unstable patterns spreads first to nearby patterns – and then then spreads still further, since these nearby patterns become unstable and destructive, too (Alexander, 1979, p. 130).
The source of the anti-patterns idea originated not from architecting built environments, but instead from a software developer outside of the core community cataloguing new patterns.
This suggestion is inspired by a story told about Thomas Edison. While he was trying to build the first electric light, he tried hundreds of possible materials for filaments. Every experiment came out a failure. At some point, someone remarked to him that all those must be discouraging. He responded that he was not discouraged – after all, he now knew hundreds of things that didn’t work.
If one does not know how to solve a problem, it must nevertheless be useful to know about likely blind alleys. This is particularly true when something appears at first to be a solution but further analysis proves it is not. Even if one knows the right answer, however, it may be important to point out particular hazards associated with that answer or seemingly trivial variations of that answer that turns solutions into non-solutions.
I have coined the term antipattern to refer to such non-solutions. An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn‘t one. If an antipattern is coupled with a pattern, it might be tempting to think of it as a pattern-antipattern pair. That would impart a certain energy to the solution (Koenig, 1998, p. 387).
This description of anti-pattern orients towards a problem-solving orientation. Bounded problem-solving distracts explorers from appreciating contexts, e.g. a filament that fails to perform under one set of circumstances may turn out to the ultimately best material in a reframed set of circumstances. Further, an anti-pattern was originally envisioned in a dialectic with a pattern, combining fruitful and fruitless paths towards generating better patterns. [pp. 39-40]
On the topic of design … I’ve found it helpful for people to have an appreciation that outcomes are not always as originally intended, and there could be emergent events over time. An illustration from Henry Mintzberg is helpful to get the idea across.
- Figure 1: Deliberate and Emergent Strategies
Henry Mintzberg, 1987. “The Strategy Concept I: Five Ps For Strategy.” California Management Review 30 (1): 11–24. https://doi.org/10.2307/41165263., alternative search at https://scholar.google.com/scholar?cluster=1077689366563106580
Incidentally, there’s the issue of whether practitioners should or should not be extending pattern language towards wicked problems.
Pattern language is not for wicked problems , said Max Jacobson, coauthor with Christopher Alexander of the 1977 A Pattern Language: Towns, Building, Construction . In addition, the conventional definition of an Alexandrian pattern as “a solution to a problem in context” when applied to social change might better use the term “intervention”, rather than “solution”.
… see “Exploring the Context of Pattern Languages” | March 3, 2018 at http://coevolving.com/blogs/index.php/archive/exploring-the-context-of-pattern-languages/
)