Living in Code

In my previous post, I introduced Christopher Alexander's work and especially his Theory of Centers. I am sure that you would like to learn more about this theory now, but you will have to be a little more patient: if you did not read The Nature of Order, you first have to understand the fundamental problem that this theory is trying to solve.

At first glance, Alexander's work is all about structure – how one solves difficult design problems. But as you start studying his books, you realize that he is driven in fact by the pursuit of a very specific kind of human experience. Alexander first called this experience "The Quality Without A Name", and he now calls it "Life", or "Wholeness". It is about creating a design whose structure is so cohesive internally, so intimately adapted to its inhabitants and its surroundings, that the experience of living within it is liberating.

What I would like to do now is to give you a better understanding of this experience, and show you how it could be applied to the world of programming. But enough talk: it is time for a color picture!

Spaghetti buildings

Pretty place, isn't it?

In a sense, what is shown here is something we all want to avoid: a shapeless blob resulting from the random aggregation of local solutions over time. For us programmers, this is probably as close as one can get to "spaghetti code" in software.

In the world of code, the problem with this situation is that the software is very difficult to grasp and to grow. The construction as a whole has basically no structure, no identity, and no rules. There is nothing to maintain or to respect. There is no apparent will behind this design. As a consequence, developers will tend to just add to the mess without second thoughts, making things even worse. What had maybe some structure initially will quickly turn into a pile of junk.

This is what happens when only local considerations guide the evolution of a design.

I will not dwell on the technical and business consequences of this approach - if you have spent some time on real-world development projects, you are probably already very familiar with it. What I would rather like to focus upon is the feeling that one gets when working on that kind of application.

When I am confronted to spaghetti code, the first image that comes to mind is that of a thick jungle. I am walking through bushes, trees and lianas, sometimes stepping into deep patches of mud, sometimes getting tangled in thorns, sometimes stumbling on dead trees. I am constantly annoyed by small bugs. I am exhausted; I am making more and more mistakes. I cannot even remember which way is north. All in all, I can be pretty happy if I manage to walk a hundred meters in one hour. I feel trapped and powerless.

Dead order

At the opposite end of the spectrum, we can find this kind of building:

This is the triumph of will over matter. Someone came up with an abstract image of what the building should be, and he had enough power on the project to turn it into reality.

In some ways, this is better than the previous situation. There is a kind of cleanliness in this place, a sense of control. It even looks very professional.

The trouble is, this order is created at a heavy cost: the design is too simple to deal effectively with real-world problems.

Look again at the picture. Would you really like to live in that place? For instance, what happens if you want to spend some time in the garden in a sunny afternoon? What about having lunch outside? Where do you sit when you want to spend some time behind the colums?

This building seems completely disconnected from the life that is happening there, and from its surroundings. It is deaf to the complexity of its context. This is precisely what happens when only large-scale considerations guide the evolution of a design.

In the world of software, this situation - or at least what I imagine when I look at this picture - reminds me of organizations with powerful architects in their tall ivory towers. These guys will come up with an abstract idea, a mix of previous experiences, gut feeling, and a couple of hours spent playing with the latest technology, and they will leave to programmers the tedious job of adapting this clean vision to the grim details of reality.

As a programmer, how do I feel in such a project? Powerless again. I have strong constraints; I have no voice over important design decisions that affect my daily work. I spend days trying to use this over simplistic design to solve complex problems. What is even sadder is that if I fail in implementing that vision, I will be the one blamed for not having been able to fully understand it.

Ironically, what I often observe in rigid organizations such as these is a tendency to produce spaghetti code even faster. Since these cultures consider code as a lowly thing, and since their developers are more often than not demotivated, they can accumulate crappy code for years and still think that the internal design of their system is the one described in their initial design documents.

Living order

There is another kind of order, somewhere between these two extremes. An order that blends the right mix of structure and flexibility. An order where both global and local needs are satisfied and reinforce each other.

According to Alexander, this sweet spot creates a feeling of freedom and empowerment. Or, conversely, you can consider that you have reached this sweet spot when you get these feelings.

It is not easy to illustrate this concept with pictures, but these ones can give you a first idea:

What I find striking in these pictures is the sense of serenity that they convey. The design is somehow relaxed and natural.

When you look at it, there are many details, but all these details fit well with their surroundings. There is no inner conflict between the fine grained details and the large-scale structure - they all reinforce each other. In Alexander’s words, these structures are “whole” and “alive”.

What is the equivalent situation in the world of software? A design where the large-scale architecture and the fine-grained implementation details work well together and do not drag me down when I am making changes to the software.

When I am working in this kind of environment, I feel creative. I am liberated from trivial technical issues, and can focus on improving the user experience of my product.

Of course, this is somewhat too good to be true. It is an ideal. For me at least, this is the true goal of software design.

The key to Alexander's work

I have tried here to describe the feelings one gets when working with different kinds of code structures, and this was done with a purpose. For me, this is the key to understanding how Alexander's ideas can be applied to software.

To understand his work, we have to become aware that we developers actually spend at least part of our lives inhabiting code structures - we live in code. Every design decision we make determines the experience our team will have in the project – trapped and powerless, or creative and empowered. Alexander's work may seem like touchy-feely stuff but it actually provides a useful heuristic. Its key lesson is that the feeling we have while working measures the quality of our design. If we manage to create this "living" or "creative" feeling through our designs, it will mean that our teams are being efficient.

What we are trying to do is thus to find the sweet spot in our design that creates that kind of liberating experience. How do we do that?

The process of creating living structures

This highly cohesive and complex order cannot be designed in a blueprint - there are far too many details to take into account, and preparing a design to this level would probably cost as much as programming it. Alexander's take on this - and we agilists will hardly argue over that - is that such a level of cohesion can only be attained through an unfolding process, where the design is constantly improved by the feedback gathered on the product itself.

However, it would be a little too optimistic to believe that an iterative process will necessarily create such an order. For this feedback mechanism to work, you need to be actively designing the software as it evolves. You need to be shaping the large-scale and fine-grained structures at the same time. If you are not doing this, you are back on the spaghetti code track, even if you apply all the other agile practices by the book.

The question is: what principles must we follow to make sure that the evolution will lead to a good design? What do you do to increase your chances of keeping a piece of code where developers feel free, empowered and efficient even after a few years of growing the application?

That is precisely where the Theory of Centers comes into play, and this will be the topic of my next post.