Unresolved Forces - Copyright Richard Fabian 2024

However, most software engineers (and leading search engines) get this figure wrong, as there are many more. If you’re in the camp that thought there was a higher number, you might be thinking about the Pattern-Oriented Software Architecture series of books¹, the Pattern Languages of Program Design(PLoPD) series², or other books like Game Programming Patterns[GPP11]. In fact, there are many domain-specific software design pattern books, so maybe you were thinking about something more modern, such as Node.js Design Patterns[NODEJS16], the patterns from Cloud Native Transformation[CNT19], or Machine Learning Design Patterns[MLDP20].

Nevertheless, these books only cover a few hundred examples. Unless your answer was in the thousands, you were still way off. In fact, you would have been conservative in your estimate in the year 2000; if you only include the list of published patterns, the number already exceeded a thousand³ as is evidenced in those collected in The Pattern Almanac 2000[Almanac00], a book published to help track the currently recognised and widely used patterns in software development.

This raises another issue. The almanac only accounted for the patterns discovered and published in and around software development. Many people forget that other areas are equally important to software developers:

• Learning and teaching patterns.
• Patterns of people management and organisations.
• Patterns of bringing about change.

The belief that patterns are limited to software engineering, restricted solely to the domain of object-oriented design, and constrained to patterns of implementation, is an incredibly narrow viewpoint. It would be like claiming you know how to cook when your culinary expertise only stretches to five different ways to make eggs on toast.

So why do we collectively believe there are only 22 or 23 design patterns for software when there are actually so many others out there? Moreover, if so many patterns exist and more are being found all the time, where are they? I will answer these questions and also explain how this state of affairs was somewhat inevitable.

There was a place—the original wiki—which kept track of patterns and the conversations around them. If you have heard of this site, which is known as the Portland Pattern Repository, you may also know that it hasn’t been updated in some time. Why is this the case? There is also the Hillside Group, which maintains a website with many (often dead) links, but they’re not as famous as the GoF book[GoF94]. Why does an exhaustive pattern catalogue for everyone to use not exist?

While a definitive answer explaining why this didn’t happen in the past would be impossible to provide, I will reveal the many forces at play that continue to make it an unlikely event. You will learn how those forces affect the established software development practices but also those processes and methodologies only recently adopted. In addition, you will learn how physical architecture and building development are similarly affected.