What does it mean to apply or transfer Christopher Alexander’s ideas to the world of software?
This is an early draft, written in one go, that I quickly wanted to publish for early feedback and as part of my current studies in the Beautiful Software Initiative. Please get in touch if you have feedback.
I can see at least seven different layers where Alexander’s theory of centers and wholeness and a generative unfolding process applies in subtly different ways to the various efforts involved in building software. These all demand further research and experimentation, and I believe it is important that we become aware of the various different directions such adaptation efforts can take, so we can be sure that we talk about the same thing and can align our efforts.
Making Alexander’s theory of centers and unfolding wholeness accessible to a broader audience in the software community
First and foremost the biggest challenge is that Alexander’s work is not an obvious resource in the world of software and it is not easily accessible unless you already have been somewhat initiated to his ideas and their influence on software design in the past. To most software people it is a barrier to leave their field behind and engage with architecture.
To rectify the first challenge, we need to pull Alexander’s theory out of its architecture context and embed it into the building process of digital artifacts. Alexander himself doesn’t seem to be too attached to architecture himself and takes a more philosophical approach in his later books. Architecture is his expertise and his medium which he uses skillfully to present us with important examples and which he ultimately sees as a lever to change significant issues we all face in our world today.
We face similar issues in the tech and software industry, which perhaps show their unintended consequences in an even accelerated form. The core insights of Alexander’s theory apply as well to our medium as they do to his. Software people shouldn’t feel like they have to learn about architecture before they can reap practical results from a methodology that happened to have originated there and should have access to a comprehensive explanation that uses our language and our context.
Software engineering in the large — collaboration
Most software projects are too large to be created by a single person, just like most buildings require a team of people to be brought to life. Every team effort requires coordination and this coordination needs to take a different form if done in the way Alexander intended. The most obvious example being that the customer or end user — the human beings that’ll be left with the built artifact and have to live with it — need to be much more involved in the designing and building process.
In a way this might be the layer where most prior art exists already. The agile movement is certainly one attempt, although I believe that it has taken on its own ideology that no longer bears close enough resemblance to Alexander’s theory anymore. Agile has over-optimized for allowing change in the software construction process, which is definitely an improvement to what we had before. It does, however, have no answers as to how the software constructed in that process exhibit properties of beauty or wholeness.
The design thinking movement formalizes the involvement of customers in the early design process with a focus on interactive design sessions and early prototyping., but without being overly opinionated on the actual process of building.
Another promising approach is Ryan Singer’s Shape Up, which the author has expressed to be heavily influenced by Alexanders work and which covers both the designing and building parts of the process.
Software architecture
This might be the most popular connection between Alexander’s work and software so far. Design patterns are likely the most formal attempt to transfer a tiny portion of Alexander’s work to software in the most direct way possible.
However, design patterns focus primarily on static structure and were heavily entangled in the object-oriented paradigm that was popular at the time. Software construction has evolved since then and many design patterns have turned into language features, also raising the question whether design patterns have just been a band aid to patch inferior tools of the past and certainly deserve a fresh perspective and re-interpretation with contemporary languages and tools.
While we’re at it though, it also needs to be pointed out that there is a whole lot more in Alexander’s theory than what made it into design patterns. Centers and wholeness and the process of unfolding deserve their own attempts of finding their equivalent elements in the digital world.
Interpreting pattern languages as a generative grammar describing just enough of the target artifact such that we don’t get dragged into too much detail too early — an extremely common problem in constructing software — seems like an area worth exploring and with great potential.
[Add description/link to Unfolding Interpreters project]
Formal computational models and theoretic implications
Alexander himself was a trained mathematician and attempted to formally specify his theory of centers. Undoubtedly, there is a lot of potential in further investigating the mathematical underpinnings and attempting to transfer this to theoretical computer science.
A promising direction seems to be abstract/universal algebra and combinatory logic that could perhaps take the formal equivalent of the fifteen properties and define the complex relations between them as algebraic compositions on top of them.
Although much larger in scope and not immediately connected to Alexander, GitHub - prathyvsh/morphisms-of-computational-structures: A visual catalogue + story of morphisms displayed across computational structures seems to be an exciting investigation.
Cognitive science and human thinking primitives
Alexander alludes to a deeper embodied character of wholeness in ourselves. Exciting research in design theory, psychology, linguistics, biology and many more fields has surfaced exciting models that explain how we categorize and how we experience our world, and have the potential to explain much more precisely how wholeness “works” and where it comes from.
While we’re still in the dark about how our brain works, we have made a lot of progress in the last few decades and understand much more about this than the popular but wrong folk theories (brain as machine, left vs. right brain, etc.) most of us still accept as common sense.
Mapping Alexander’s theory to latest research in cognitive science could fill in the important blanks that Alexander left us with about our selves and have the potential to chart new and exciting ways to define what it means to create beauty and wholeness.
Most promising to me appear basic structures of universal metaphors and kinesthetic image schemas in embodied cognition, that seem to map exceptionally well to what Alexander describes as “feeling”, free of opinions and fashions and shared between most of us across cultures. Spatial metaphors seem to connect equally as well to the fifteen geometric properties and could potentially explain how we perceive well-formed centers and why they have profound neurophysiological effects on us.
User interface design and user experience
Coming back to software, another important part — and perhaps the most important one — is the part of the software that presents itself directly to the person using it. If software has anything like geometric properties then they sure occur in the user interface. Deeply interwoven with psychology and embodied cognition, human interface design might as well be the discipline that has most to learn from Alexander (and the least prior art to my knowledge).
As the world shifts from using classic input devices like keyboards and pointing devices to touch screens and all kinds of sensors embedded in mobile phones and wearables, and with a future of augmented reality around the corner, there’s lots of work to do to make future software a more humane experience embedded in the more and more digitalized environment around us.
Future of programming and end-user programming
Programming is fundamentally about building tools, which is a step removed from the creation process. We’re not creating something directly, but rather create something that others can use to create something else. It is here where Alexander’s main criticism about contemporary architecture applies directly to software: the people using it are not the people designing and building it. As in architecture, we have created a world in software where we, too, discriminate people from experts and have built a whole industry based on that chasm.
If a better future for architecture is rooted in involving everyone more in the building process, so that the people who exactly know or feel what they need and want are empowered to design and build these things themselves or at least are much more involved in the process of creation, then software needs to be headed into the same direction.
Bad software, designed without empathy, that restricts people to only follow strict procedures to achieve one specific goal, has trained millions of people that software is cumbersome, inflexible, and even hostile and that users have to adapt to the machine, if they want to get anything done. The future of computing should be very much the opposite. Good software can augment the human experience by becoming the tool that’s needed in the moment, unrestricted by limitations in the physical world. It can become the personal dynamic medium through which exploring and expressing our ideas should become simpler rather than more difficult.
If you liked this post, you might be interested in my Notes on The Nature of Order, where I publish my notes as I’m working my way through Christopher Alexander’s magnum opus The Nature of Order. You’ll also find a link to a Telegram group there, if you want to stay in touch about this and connect with other people who are interested in bringing his ideas to the software world. See you over there!