Unresolved Forces - Copyright Richard Fabian 2024

Where to find them

We can find some pattern sources by looking at the human aspects of software. Those we find can be interpreted and assessed through the objective measure of wholeness. We can look at studio layout, UI, and the design of applications in general. We can look for patterns in human resources and patterns for rewards. Through the lens of survival, we can hunt for patterns providing a better working environment, both locally and at the scale of corporations. We can look for patterns of how we should develop processes, design code, and test our software. All these systems can influence and be influenced by other elements, hence the systems theory aspect.

The physical environment seems the most obvious. We have a long history of working in offices and have worked with other humans for thousands of years. We will have a sense of quality for these areas. We can trust some of our instincts on what will make things better. A Pattern Language[APL77] has some suggestions on this front, as work itself is not a new invention by Silicon Valley types—at least not until they reinvent it as a ‘side hustle using equipment borrowed from and backed by a like-minded investor who takes a large cut of your profit as long as you follow their guidance’.

The quasi-physical world of the end-user experience is the next most obvious. Applications are lived with. They need good geometry and follow the patterns of breaking symmetry to indicate information. Mostly, you can appraise them by the same overwhelming agreement method. Beyond feeling, we have many good rational metrics supporting us, such as measuring time and motion—but not for evil this time.

User stories are bountiful hunting grounds for patterns. There are undocumented patterns, such as Exit through the gift shop ¹, which are retail design patterns. These are patterns of museums and other attractions that offer free entry. The forces at play are a need to supplement income without ruining the experience in any way.

Exit through the gift shop gives the patron the advertising-free experience they desire and invades their space with a request to consider showing some appreciation or buying a souvenir only at the last moment. We’ve seen that websites started doing this with the hover-out showing a ‘Please don’t leave’ message. There are likely other design patterns you can find based on the literal actions of your users. These are UX patterns. Look for the action, find the driving intention, and see if there’s a mental model you can infer.

In his book Hooked[Hooked14], Nir Eyal talks about ways to discover these patterns by considering the feelings people have and how they respond to them. Moving away from engaging users, we can still analyse their reactions to emotions to gauge the kinds of forces at play.

It should be possible to identify some patterns from a current situation via the negative forces that are present. Some lack or some present pain is often the motivation. Deduce from what is clearly or not so clearly missing. In the work on the Eishin Campus, ‘paths connecting classrooms exposed to rain’ and ‘separate classroom buildings’ were latent behind the ‘covered passages’ and ‘one building for all classrooms’ requirements naturally supposed by System B ([NoO2-02] page 366). Look at what you presume and think about why it’s assumed and what it means. Look at the opposite options. Remove an obvious requirement to identify whether change is needed. What nice things are killing you?

If you are in a monolithic codebase, the ability to reach all other code from anywhere is an anti-pattern but also a guide to the pain. Before splitting the code into smaller pieces, you will likely have long build times because monoliths tend to have lengthy build processes, collecting everything together at the last minute. These pains might not be noticeable until you consider what you don’t have. When making architectural decisions, we trade one pain for another, but often, there is a path to solving both when you look hard enough.

James Coplien’s commonality and variability analysis[MPDfC98] is a good source of patterns in software. Most GoF patterns fit this structure. We view something as a static attribute, so we introduce an object or abstraction to allow it to vary. You can often find patterns in software in how we deal with different kinds of design requests.

For example, when we must vary what we construct, we make our constructors into variables: the Factory Method. In C++, you can’t create a pointer to a new object constructor, so you must make the constructor into a function or an object. This is not an object-oriented design pattern, but an idiom of C++. The parameterisation of factory methods, however, is applicable in most languages, meaning the core pattern holds, even if the presented forms do not illustrate invariants of all solutions.

What is common to some data is a transform. What is common to some transforms is an algorithm. What is common to some algorithms is a paradigm of programming. What is common to different paradigms is goal definition. Commonality and variability analysis allows you to find patterns, no matter the scale, but it also helps you find the hierarchy in your language.