# The Unselfconscious Way Of Building

September 28, 2019

Here are some notes on

Christopher Alexander, like in talks about the design process in the abstract. But the book imparts concrete understanding.

There is an artificial distinction between the two design processes. The selfconscious and the unselfconscious process. Design, be it wireframes, blueprints or software, aims to solve a problem. The solution doesn't exist in a vacuum. Context is vital. Take an example of the human body. It is a design the evolution came up with. The cells exist and functions within the context of the organisms. And organisms within species.

What is the problem? Here, the definition of the problem is a misfit between the form and its environment. The misfit is not resolved unless the form satisfies its environment and vice versa.

In the unselfconscious process, the designer is just an agent of change. The process is self-organizing. It relies on immediate feedback from the surrounding. Consider how an Eskimo builds an Igloo. If its too warm inside (a misfit!) the designer just digs a hole. He did not do elaborate planning before digging a hole. Contrast this with a Skyscraper. A large team of engineers and architects put a significant effort to deliver a project of such magnificence. We plan it to perfection. In a top-down fashion. And if a fault is detected in the building, we need an expert to deal with it. A layperson has no role here.

Preexisting knowledge and directness of action are essential properties of the unselfconscious process. The Eskimo intuitively knew that he needs to dig a hole. The unselfconscious process of design, unlike architecture or engineering, is not taught academically. The skill is specific to the context. And perhaps, it is passed down as a tradition. Trial and error play an important role here. Repeated trial and error leads to a position of a fit between the artefact and its context. It may take a long time to reach this equilibrium between the environment and the form.

In the unselfconscious culture, change for the sake of change is discouraged. Once the system starts to work, it is left untouched. Until something changes in the context, causing a misfit. A complex system built this way is naturally divided into subsystems such that when one subsystem is modified, there is no cascading effect on others1. This localizes the error and as a result, make the system, as a whole, more robust.

The process of maintaining and evolving software can be unselfconscious. The project will grow into a robust and functional product if the maintainer fixes bugs and only add features that are absolutely necessary to solve its user's problems. The user, like the Eskimo from the earlier example, has to be in the loop. Giving the developers feedback, raising flags or better submitting a patch.

Decoupling of subsystems is the most significant point of leverage in software. If done correctly there is a massive gain in maintainability. Also, thoughtful decoupling removes the chance of cascading effects of tweaking the sub-components. Which makes iterations cheap. More iterations in less time imply a dynamic equilibrium can be reached faster between the solution and the context in which the problem exists.

On the other hand, there is the selfconscious process. It is not guided by the immediate feedback from the environment. It is the process of intellectualization. In the book, the author offers an example of designing a kettle. You start by gathering the requirements. Quantitive or qualitative. For example, its capacity, the temperature it heats to, how much it costs, and how should it look etc. A subtle point about requirements: you will only notice when it is not satisfied. Each requirement is an invariant of the problem. It defines the context. The more invariants, the lower the chance of satisfying all of them at once. For a high number of requirements, the likelihood of meeting all of them at once will be extremely low2. This makes it challenging to produce forms that work. The designer, when working in the selfconscious paradigm, must rely on rigorous formal methods.

### NOTES

1. The tight feedback loop will enforce a more modular design. And modularity will ensure quick modification of subsystems.
2. For n independent requirements we can estimate the likelihood to satisfy all of them at once will be: $$1/2^n$$
Keep in touch!