Learn to recognise patterns
Recognise patterns and translate them into a better and more powerful
representation. I want to do the reverse of Christopher Alexander and publish
this book—my
A pattern as a procedure, a transform, a process
A pattern is not just the recognition of a potentially better situation but of that and the operation in tandem. It’s the recognition of a way to transform and often a process that produces itself. We must shed light on the steps, not just shine a beam on the result of its application. When we recognise patterns, we need to reveal the original discomforts that induced these resolving actions.
We must perceive the lack that preceded the pattern to understand the forces at play. Without awareness of the pain the context was causing, we cannot be sure we have satisfied the situation to the highest degree. Neither will the pattern user.
Patterns are present at all scales and in all networks of interaction, not just at a single level. Even a single pattern might apply across multiple levels or be appropriate across various domains. The types of patterns are numerous and far-reaching because all it takes is for a self-supporting sequence of operations to come about repeatedly for them to form. So, where could we look for them?
Product patterns
Many patterns we can verify because elements of the world created for us are product-centric. The product can be an application or the way in which that product is communicated to the potential users.
- UI and UX patterns, solving problems of understanding the user’s mental model and guiding them through your app.
- Patterns of build processes, how to reduce wasted time and get the best feedback as fast as possible.
- Deployment and delivery patterns, delighting customers and resolving problems before they happen.
- Patterns for paring back and cutting features, trimming projects to the right size.
- Patterns of building for the life of the customer, becoming a part of a user’s life and gaining great credit through extended word-of-mouth.
- Marketing patterns, getting to those who would care and how to avoid negative reviews.
Organisation patterns
Other patterns we can verify because they are about how we work and live. They are related to social groups, connections, and communication patterns.
- Hiring, teamwork, training, and firing patterns, improving the sense of community and avoiding hard-to-resolve mistakes.
- Patterns of retaining talent or investing in people, solving the problem of knowledge loss and immaturity in teams.
- Research, knowledge, learning, and teaching patterns, pedagogy for all.
- Patterns of organisational sizes and direction, ensuring teams are motivated by the goals of the organisation by accepting the possibility of change in either party.
Process patterns
Some patterns can be sought in the way we work. How we grow, change, evolve. How we reward and how we respond to failures of our systems. Most of these patterns will need to exploit an understanding of systems theory.
- Development process patterns, how to reduce waste and increase pace, how to engage everyone in creating value.
- Patterns of extending and new versions, how to avoid alienating your customer while engaging the new.
- Scheduling patterns and sign-off patterns, avoiding costly extensive tick-box exercises that inhibit fast turnaround.
- Handling permissions, secrets, and licenses, that is, the patterns of stress-free law abidance.
Refactoring and maintenance patterns
The least verifiable patterns will be those of the construction process and sub-products. Source code and processes to verify and validate source code will need careful attention.
- Code structuring and migration patterns, how to structure for easy, safe change and future comprehensibility.
- Patterns of debugging, solving problems, learning, and preventing so bugs stay fixed.
- Maintenance patterns, enabling the future to respond as fast as the past.
- Patterns of planning and refactoring, that is, approaches to impact our willingness to make changes and reduce the apparent waste of effort created by detailed, far-distant plans.
- Patterns of maintaining live services and continuous improvement, for when you have to keep the service up and running no matter the weather.
Where else?
New patterns will emerge as people change and what they value changes. It is a timeless way, not because the patterns are timeless but because people interact and have needs, and though the possibilities are endless, some configurations recur with great regularity.
We should look for new movement patterns, in both leisure and work. Patterns emerge from the configuration of space and the natural interaction of people. The modern situation of a train station is simply a configuration of space from which the motion of people emerges. There is something timeless, like the application of the laws of physics, but it is contemporary in its realisation.
Judge principles
When reading other works with programming principles, consider where they come from. Are they principles, or are they patterns in disguise? Sometimes, principles are just principles. Keeping functions short and using descriptive names for identifiers are guidelines for how to do the work. However, some principles emerge from momentary forces in contexts.
I think some of the SOLID principles might be design patterns. For example, the single responsibility principle resolves some forces of code maintenance in the context of recognisable repetition in code. It’s not a solution, but it does constrain solutions, so it feels more like an Alexandrian pattern, a simple one that helps guide to a better set of solutions to many situations. This is also one of those patterns that applies at many levels; it’s both language and domain-agnostic.
Interface segregation seems like a property to me, not a pattern. It is a positive attribute you see when unfolding a design under the forces introduced by new use cases. The value in this property is the recognition of the problem caused by having one and only one interface. The accidental coupling is revealed to the reader of the principle in much the same way important moments of human lives are revealed by many Alexandrian patterns.
Dependency inversion is a pattern in my eyes. The concept does not feel like a principle, but it’s quite easily interpreted as a process to reduce coupling when the forces of variation are present. Knowing this pattern leads to many other patterns where options must be introduced without giving knowledge to third parties who should remain indifferent and disconnected.
Look for forces
Patterns exist as a response to problems. Problems exert forces on elements of a context. Look for those forces. The pain points are what differentiates a pattern from a set of instructions. Seek them out in bug reports and feature requests. Look for them in the requirements and features of languages. A programming language might not be a good place to find a pattern language, but it can spawn a pattern by its limitations or opportunities.
When you are ready, learn about the many forms of waste in lean manufacturing, as waste is an ever-present force in most organisations. DevOps is an extension of recognising waste in IT and provides many clues to guide pattern recognition for processes.