TLDR; Design patterns are often seen as a comprehensive set of options to choose from when structuring code. The word “pattern” is interpreted as a fundamental rule. This misunderstanding leads the focus away from where it should be: getting better at making simpler code. We should call design patterns design examples instead, giving them the value they deserve.
The biggest challenge in software development has never been learning syntax, knowing how to use tools or libraries or even inventing new algorithms. The biggest challenge is how to structure code so that its complexity stays manageable.
Let’s agree that restructuring code, as opposed to adding features, always needs to result in code that is easier to understand. The more comprehensible, the easier it is to onboard new team members, the more maintainable the code is and the easier it is to expand upon.
There is a word for something that is easy to understand: simple. So I think we can agree that there is one design rule, or ‘pattern’ by analogy, that always holds:
Make it simpler.
Now let’s look at the practice of studying, memorizing, testing and trying to apply design patterns: does it guarantee simpler code?
- Since no situation in code is ever the same, the only way to see if a design pattern works for a code base is to try it. Refactoring code to a new structure is a significant time investment. However, everyone needs to make time compromises. Especially in software, where customers are won primarily by being the first on the market. So after the second or maybe third attempt to fit our code into a design pattern, we settle, usually for the last attempt. That is far from a rigorous analysis of which of all the available design patterns actually makes our code simpler.
- The suitability of a structure changes with features. What is first a great fit can be completely unsuitable when some features are added or slightly changed. A successful software business is flexible, in other words, features change all the time. This means that the process of finding the correct structure, refactoring, should be repeated all the time. If we feel we need to sift through a large variety of design patterns every time we need to come up with a new structure, we are more likely to refrain from refactoring, leading to more technical debt.
- Software developers compete by intelligence and general programming knowledge. Design patterns form a complex subject, more so if you don’t recognize that they are usually not very rigidly defined and also because they are almost always applied with exceptions. Developers will feel a strong urge to master this complexity to feel competent, more secure or more impressive. They will put a lot of time in studying the subject. Since we all want our investments to pay off, this creates a strong bias towards applying design patterns.
These are a number of practical reasons why design patterns work against making code simpler.
But the biggest problem with design patterns is this: the word ‘pattern’ is interpreted as a description of a fundamental, recurring aspect of code structure. Names of various design patterns as listed by a popular book are commonly used in discussions, assuming this is the best way to communicate the essence of the code that is described. So when I buy a book about design patterns, I expect it to describe most situations that my software project can be in, and tell me how to handle them.
The concept of software design patterns is said to be originally inspired by a book about patterns in architecture. In architecture, where the problems that buildings and city planning need to solve don’t change, a set of patterns can be expected to be distilled after some time and to remain more or less comprehensive. But the nature of code is very different. Once something is solved in code, it doesn’t have to be solved again. The analogy is completely inapplicable.
People are prone to a cognitive bias called Clustering Illusion. We want to see patterns everywhere. I believe this is why we are unreasonably susceptible to the promise of design patterns. But as shown above, design patterns carry a false promise.
This doesn’t mean that design patterns are useless. As long as we call them design examples. This makes them as suitable for study as any other code example out there. Examples can help us, they can be great to study, but this is inferior to honing the primary skill of simplifying: changing code and asking yourself if it is now easier to understand.
Here are some ideas on how to make code simpler.
