Unresolved Forces - Copyright Richard Fabian 2024

The abundance

Before the GoF book[GoF94] was released, patterns were present and known about by quite a few people. However, the published design patterns were not clearly labelled as such. Some were described as processes, others as guidelines for a project. But discoveries were soon labelled as patterns after the GoF book was released. It’s as if the presence of the book legitimised the terminology of patterns for software engineering. However, the quality of these published patterns varies considerably. Those published in the PLoPD books¹ went through a shepherding process, so they should portray the better-curated side of the movement, but even they are lacking in some surprising ways.

The shepherding process helped people write up the patterns they had found. It was intended to guide a pattern author to produce a text that fulfilled the criteria of a design pattern and provide feedback on whether the pattern was faithful to the concept. In practice, this was achieved in a fashion comparable to a writers’ workshop. Any pattern that went through the process should be free of obvious mistakes and, by virtue of having come out the other side, should be worth reading if you encounter a similar problem.

As a modern reader reading these patterns, many strike me as both hopeful and naïve. Many of them aren’t even patterns. They suffer from similar problems to those of the patterns in the GoF book. At the time, the process of finding patterns and the form of patterns were still only vaguely understood by many. And there were other problems. Due to their nature as a collection of proceedings or from different books with different authors, they are inconsistent in their presentation, content, and size. All of this adds to the difficulty of using and reading them.

The patterns presented in Christopher Alexander’s A Pattern Language[APL77] are many—the book includes 253 patterns in total. But they are at least all readable, consistent, and openly aware of their validity. This last point is made clear by a notation on the patterns: a single or double star, or the absence of any. Alexander and the other authors were very aware of how difficult it was to be sure about whether a pattern is good and wholesome.

In this sense, each pattern represents our current best guess as to what arrangement of the physical environment will work to solve the problem presented. The empirical questions center on the problem—–does it occur and is it felt in the way we have described it?—–and the solution–—does the arrangement we propose in fact resolve the problem? And the asterisks represent our degree of faith in these hypotheses.

— Christopher Alexander, A Pattern Language, p. xv.

The term hypothesis is used to describe each pattern, pointing out their stance on their discovery. Perhaps also indicating a slight hedging—a self preservation if it turns out they were mere wishful thinking. Even so, they were conservative in handing out their approval of the patterns in the book. Very few attained the two-star status reserved for those patterns describing invariants found in all wholesome solutions to the problems they framed.

An abundance of content is not always a good thing. In the realm of software design patterns, it was not beneficial for pattern authors or consumers. Without curation and strictly enforced well-defined guidelines, many submissions were published regardless of whether they were usable, correct, or even found in real life.

As I researched these older patterns, I became disheartened and felt some developers included these hopeful patterns just because they wanted them to exist, thinking it would be nice if they came true. I can understand the thought behind doing so and how a charismatic author might weave a good tale and convince a group or shepherd to sign off on the work. Other patterns appear to show off what the authors knew or were able to solve. These patterns anger me. Tainted by ego, they are all one-off solutions and never patterns. I believe their purpose is not to teach but to stake a claim.

Reading these early patterns, you get the impression that these egoistic and hopeful specimens were taken from samples of one or fewer. Sometimes, they sound like an idea of something that might exist. Writing down what you hope to be true is a mistake many non-fiction authors make, and I hope to avoid doing so here.

As the movement aged, and with later books, the quality and pattern-ness of the published patterns increased until the last books comprised only very well-curated content. The last PLoPD[PLoPD5-06] book contains some outstanding patterns. I have trouble finding fault with many of them, even though most still seem to be solutions to specific problems rather than principles for generating solutions.

Because of their abundance, even if all of the published patterns were proper patterns, their users would suffer because there’s too much to take in. Part of the charm of the GoF book is that it only requires you to learn 23 patterns. With thousands out there, where does one start? Which pattern collection do you browse first? Whose patterns are foundational? Whose would be helpful in your area of development? Again, this is a problem stemming from abundance without curation and cataloguing.

Our modern world has countless songs and films, and finding one to suit our tastes is undemanding. With patterns, it’s a different story. Is this simply the difference between entertainment and engineering? I don’t believe so. The problem is how we search for what we want. An abundance of movies is not a great disadvantage for the consumer; there are genres, and people know what they want. With patterns, the genres are unknown and sometimes, we’re too ignorant of our need to know we should even begin the search.

So, while literal abundance is not to blame, without the necessary protections, it became a breeding ground for many other problems. It was likely the root cause for why many better patterns were lost amidst the noise before it all turned to silence.