In my last post, Living in Code, I talked about a major goal of design: finding the right balance between order and chaos, between large-scale order and fine-grained adaptation to detail. In Alexander's words, this is all about creating "living structure".

Alexander has spent decades studying what makes a structure "alive". His work has led him to define a complete theory of design: the Theory of Centers, described in detail in his four-volume series The Nature of Order.

This is a very ambitious work, the result of a lifetime of practice and study. I was struck a few years ago when I read one of the early reviews for the first volume:

The Nature of Order is not only a summa summarum of what Oxford University Press has called "The World of Christopher Alexander", but it is surely one of the most ambitious books ever published. If its profound argument -- that order in both nature and in what we build are essentially the same -- is ultimately understood and accepted by serious readers it may prove to be one of the most consequential works Oxford has published in all its 500 years.

William McClung
special project editor for Oxford University Press
former senior editor of the University of California Press

You don't find reviews like these for many books.

However, people who read The Nature of Order will probably have a hard time seeing how it relates to the field of software. After all, this is all about buildings and physical structures - what can we learn from a field that seems so distant from our own? This is precisely the topic of this post.

To get us started, here is a quick overview of this theory.

Centers

If we are to talk about this so-called Theory of Centers, there is an obvious question facing us now: what is a "center"?

As far as I understand, a center is simply something worth noticing in a structure. For instance, in a human face, you will find centers such as the eyes, the nose, the mouth, the forehead, etc. You will also find centers at a finer level of detail: the eyebrows, the eyelashes, the iris...

One may also identify centers in a city - the town hall, a park, a church, a monument, but also a neighborhood or an important road.

There are two important things to note about centers:

• A center does not necessarily stand apart from the structure to which it belongs. If you look at a nose, for instance, you will notice that it is pretty much continuous with the face itself. The boundaries of a neighborhood are not always clear, even when the neighborhood itself is well known.
• Centers can be found at different levels of scale. The face itself is a center within the structure of the whole human body, and it is made up of smaller centers, which are themselves made up of even smaller centers. The same can be said for countries, regions, towns, neighborhoods... down to a piece of furniture in a room.

Systems of centers

According to Alexander, what matters most in a structure is the relationship between centers. Every center creates a kind of "field effect" that influences the centers around or inside it in a positive or negative fashion. The centers of a given structure thus reinforce or weaken each other, resulting in an overall strong or weak design.

In The Nature of Order, Alexander introduces this concept with a very simple structure: a rectangle.

As it stands, this structure is quite cohesive. But let's suppose that we just add a little dot somewhere:

As you can see, this very small addition just weakened the whole. There is now something clearly wrong with this design, even though it's caused by a very minor change.

On the contrary, this small dot could have been placed in such a way that it strengthens the structure, just like this:

In this case the dot benefits from a field effect created by the lines and the corners. It reinforces the symmetry of the figure. One could go a step further and realize that there already was an invisible center there - what Alexander calls a "latent" center.

The 15 properties of living structures

Alexander has studied extensively what properties were exhibited by living structures. He compared hundreds, maybe thousands of structures, trying to understand each time what living structures had that lifeless ones had not.

Over time, he came up with a list of 15 properties. These properties are different kind of relationships between centers that help create a living structure. The more the centers of a given design reinforce themselves through these 15 properties, the more life the structure will have.

These properties are the following:

• Levels of scale
• Strong centers
• Boundaries
• Alternating repetition
• Positive space
• Good shape
• Local Symmetries
• Deep interlock & ambiguity
• Contrast
• Gradients
• Roughness
• Echoes
• The Void
• Simplicity and Inner Calm
• Not-separateness

I will only present a few of them here, in particular those that I find relevant to the field of software. For a complete description, there's probably no substitute for a thorough reading of tome 1 of The Nature of Order: The Phenomenon of Life. You will find there dozens and dozens of pictures that illustrate them in great detail.

In the meantime, here is a quick overview of some of them:

This tiger face is filled with centers. The eyes and the nose are the Strong Centers of this face. There are many Local Symmetries, starting with that of the whole face. There are Boundaries around the eyes or the nose. There is Contrast in the black and white colors of the fur around the eyes or the nose. There is Alternating Repetition of the stripes. There is Roughness in the fact that the stripes are not perfectly regular or symmetrical.

Structure Preserving Transformations

We have been so far focused on the static properties of structure, but this is only part of the story. One of Alexander's main arguments is that living structure is not built from a blueprint, but evolves through a specific process of piecemeal growth.

In this process, centers are added and modified over time in such a way that they reinforce each other more and more. Latent centers are turned into strong centers. Weak centers are pruned out. Overlapping centers are differentiated. Alexander calls these evolutions "structure preserving transformations"

In volume 2 of The Nature of Order, The Process of Creating Life, Alexander explains how the 15 properties introduced above can be seen as the core structure-preserving transformations. At any step in the process, you can enhance the structure by adding or modifying centers in such a way to you reinforce one of these properties - adding contrast, introducing or strengthening a boundary, etc.

Centers in software

Back to software now. What is a center in our world? The main difficulty we face is that we are not talking about physical or graphical structure, but only concepts. And this is precisely what I think centers are in software: concepts.

When we talk about a piece of software, we talk about a system of concepts. These may be modules, functions, classes, or more fuzzy arrangements of these basic elements - what is important is what we imagine, it is the entities what we hold in our heads when we think about our application.

As an example, let's suppose that we are developing a desktop email client. We will probably end up with data structures representing a message or a contact: these are strong centers in our application. They are probably part of a "model" module, which is itself a center. The UI module is also a center, built as a structure of smaller centers such as panels, components, or the whole undo/redo mechanism. There is probably a persistence module, and a module module responsible for interacting with remote mail servers. This "mail server access" module probably has important centers such as the parts responsible for handling POP, SMTP and IMAP connections.

What we are basically saying here is that anything is more or less a center, which is of no real help. The theory takes its importance when we talk about the relationship between these centers, or better yet: the evolution of these relationships over time.

The process of growing centers

Let's go back to the very first stages of the development of our mail application.

On the first day, there are only a few files, maybe even only one - just what it takes to get a list of messages from an POP server and display the titles in a grid.

After a few days, it is possible to send messages, and the connection to the SMTP server has been made a little more robust. The code responsible for the connection to the server has been separated from the code that manages the user interface, and they both lie in their own packages. The more different these two modules become, the more distinct their responsibilites, the more Contrast there will be in the overall structure.

A couple of weeks later, the application manages threaded discussions. The code responsible for the persistence of data was initially scattered across the application, but it has been regrouped into its own module, increasing once again Contrast at the module level.

The code for the user interface has grown fast. Submodules have been introduced to separate the different functions within the UI module. With this tree-like structure being replicated in all other modules, the application is getting Levels of Scale that help developers better find their way in the code.

The next weeks are dedicated to the support of other mail protocols. It does not take long before the IMAP, POP and SMTP access services are brought under a single interface, offering an homogeneous access to the user interface module. These three centers are reinforced by this newly introduced Symmetry.

One of the benefits of the new mail server access interface is that other modules can use the functionality of the mail access module with a very limited set of APIs. These APIs form a Boundary around the mail access module. The same principle has been used for the persistence module, and it is also used all over the application when developers make sure that the internal state of their classes is not exposed to the outside world - this is just the well-known encapsulation principle.

As the number of modules grows, the developers start applying uncle Bob's lessons and take care of organizing the dependencies so that modules that change the most - usually the UI - depend on more stable modules, and not the other way around. This creates what I call a "dependencies diamond" - a diamond-shaped graph with the more volatile modules at the top and the most stable ones at the bottom. This structures exhibits a Gradient of stability.

I will present these properties in more detail in future posts. At this time, the only property that makes absolutely no sense to me in the field of software is The Void. Something about the code we don't write, maybe?

An heuristic for growing code successfully

At a time where agile methodologies are gaining more and more momentum, there is a risk for unprepared developers to assume that they can spend less time thinking about the design of their application. It is too easy to miss the fact that agile projects succeed provided that the design activity is not reduced at all, but on the contrary expanded and spread throughout the whole project.

In this context, what we need is a set of guidelines and principles that help us grow the design over time in a positive fashion. Instead of getting the usual decay that leads to younger and younger "legacy applications", we need to learn how to improve our designs over time. This is precisely why I think that the the Theory of Centers can play an important role in the way we see and build software in the future.