Unresolved Forces - Copyright Richard Fabian 2024

The unfolding process

In The Nature of Order, Book 1[NoO1-01], Christopher Alexander related the quality without a name to his fundamental properties, piecemeal growth, and generative construction. Before he reached this point, he had been looking for the property everywhere, finding inspiration in the strangest places. One moment of note is when he began to see the indescribable quality in antique Turkish and Persian rugs. Once he started recognising it there, the fundamental properties became evident to him. Around the same time, he was experimenting with patterns and structures to find out if there was a repeatable activity that could prove something deeper was going on. His experiments showed, without room for credible doubt, that even though people had different tastes and opinions, there was a test they could perform where they would overwhelmingly agree¹ on what things were better than others.

However, the surprising, and the important, thing is that the mirror-of-the-self test does not correspond to our everyday sense of what we like. When we really concentrate on the life in things by checking how much self they have, we find that sometimes, yes, the test does confirm our liking, or our preference. But at other times, it gives us quite different results, which are not stereotypes of good design but which surprise us, shock us out of our complacency, and make us recognize that we are confronted here with an autonomous phenomenon, that has a great deal to teach us.

— Christopher Alexander, The Nature of Order Volume 1, p. 334

Those following the works of Christopher Alexander might notice he referred[NoO1-01] to the writer and founder of the metaphysics of quality, Robert M. Pirsig. What Alexander said about quality may resemble the arguments in Pirsig’s first work[ZatAoMM74], where the reader is invited to think of quality as ineffable, neither subjective nor objective. To me, it was clear he thought it beyond our current means of understanding. However, Alexander’s writings claimed we could understand it[TTWoB79].

Pirsig claimed quality was a universal feature[ZatAoMM74], that we could determine whether something was good or bad. However, he also claimed we mightn’t know why. His thesis relied on humans to interpret the world and make judgements to find the quality of something. Pirsig seemed unable to escape using human judgement to perceive value.

Pirsig’s later work[Lila91] pointed to freeing the human mind of its limits to see more freely and consider things without inhibition. But he remained stuck on the requirement of human perception right up until the end.

Alexander, on the other hand, kept pursuing the properties of quality. His research continued towards a technical solution to the definition of quality in all things.

As Christopher Alexander’s work progressed, he moved away from patterns and towards this more fundamental building block of architectural form[Grabow83]. He sought to understand where the patterns came from and discovered their essence in architecture as the 15 fundamental properties. He could describe existing patterns in terms of the fundamental properties and referenced them in The Nature of Order, Book 1[NoO1-01] at the end of every property section. I believe they can predict new patterns, firm up the weaker ones by making what was missing visible, and can be used to find fault and dismiss others outright because they are incomplete or idiomatic.

The fundamental properties of forms are viable in many human crafting and construction domains. However, they’re not directly applicable to code as there is little geometry in code itself. Instead of local symmetries, we have variability and commonality. Instead of deep interlock and ambiguity we have polymorphism and procedure. The fundamental properties of code are in a different reality, where there may be fewer dimensions but many more domains.

The fundamental properties of forms apply to application development, where it touches the user’s reality. Many of them are helpful in user experience and interface design. Some help with problem domain analysis, as the problem is usually real-world. But for the code itself, they do not fit, akin to how they work well for animals and plants but not for DNA.

When a domain has different rules for what makes a thing beautiful, the fundamental properties change and the rules of unfolding change in line with the constraints and options of that domain. We have to find the beauty by some other means and provide convincing arguments as to their value, as we will not have overwhelming agreement by default when we find the best properties.

When it comes to code, unfolding always seems to be one of the following:

• Recognise a lacking option in the code and expand upon it.
• Recognise some commonality in the code and collapse it.

We have found at least one property, that of differentiation or combination. Fixing code like this links to levels of scale or strong centres. But most properties are not present. Unlike the real world, we don’t have a property of Alternating Repetition, or repetition in general, as duplication is something that the code does itself. Duplicated code has no value, and repetition often leads to unintended variation.

So, what are the 15 properties of software? They aren’t the same as building and architecture, as there is no geometry to the habitability of source code. Perhaps Melvin Conway found them in his relatively obscure paper Towards Simplifying Application Development, in a Dozen Lessons[TSADDL]. But rather than list them, he stumbled across them all in one step with the transform-in-place application development technique. All properties of unfolding code may come from this. Introducing and linking a new element to another changes the application without ever breaking the completeness. Although the process feels like unfolding, I can’t see a world where this is how we develop applications in general. I don’t have the imagination to envisage developing something as complicated as a word processor with his approach.

We may have two super-properties—mutation and extension. The first super-property of mutation comprises a few transformations hidden within refactoring actions, things we do to code as a matter of course and believe are safe to apply:

• Extracting functions.
• Making code generic when it’s called for.
• Splitting classes into different parts with different responsibilities.

These are all ways code unfolds while its capabilities remain unchanged. But then we have the super-property of extension—of added features. The options for features are particularly numerous. To name a few abstract variants:

• New parameters for existing methods.
• New actions we can perform on our data.
• New data on which to perform the actions.
• New ways to receive or interpret data.
• New events to respond to or generate in response.

There are many patterns based on subsets of these features. Some patterns are primarily feature work, while others are refactoring. However, all software design patterns appear to decompose into one of these two super-properties. I hope I am wrong and someone does find a finite set of forms, but they will only find them if they start by looking at the patterns that use them.

The unfolded design

The actions of an agile process are iterative, incremental, and use small steps. Agile development tends towards an unfolding process. The teams are often feature-oriented for this reason, not discipline-aligned. When organising teams around a feature, visible progress becomes the only necessary metric. But if your features must cross team boundaries for communication, they will have to team up at a higher level to achieve any goals, increasing communication overhead.

Unfolding, or progress, has to be completed as a single step. Otherwise, the process isn’t clean. When tasks are ‘thrown over the wall’, the system is not in a wholesome state at all steps—it’s no longer unfolding. It’s much more productive to have many smaller intermediate steps with no visible improvement but whereby each step leaves the system in a wholesome state. Think of it like getting from one platform at a station to another. You could try to cross the tracks, but that’s not safe. Instead, you go up the stairs to the bridge (no visible progress), cross the bridge (minimal, irrelevant progress), and finally walk down to the other platform (finally, some visible progress).

The physical building patterns process had everyone grouping around problems and resolving them. The trick was to tackle the problems that made future problems easier to solve. When they resolved the overarching problems of space and utilisation, most other problems had simple solutions. In software, we need to find out which patterns are our patterns of space and utilisation. Procedural design suggests the most important patterns are data structure and procedure design. Object-oriented design suggests the best patterns concern representing the problem in the domain object model. The Domain Driven Design approach suggests the most important patterns lead to understanding the different interpretations of data and available actions on those interpretations.