Excerpts the works of Christopher Alexander

Yesterday I read some excerpts from Christopher Alexander's "A Timeless Way of Building" and "A Pattern Language". I first heard of Christopher Alexander during my undergrad and have been meaning to read some of his works so I am glad I finally got an "excuse" to do it.

Alexander's writings was pretty much what I expected based on his reputation with a zen-like prose and insightful observations. In the flower and the seed he talks about the quality of living things - the quality without a name. To an engineer the concept seems very vague yet at the same time it feels so familiar. The QWAN can not be made, but must flow out of our work on its own. Since the QWAN can't be made we can not bring it into life through some monumental task. We can only generate things with life through an incremental process where each part is shaped individually to be in perfect harmony with its surroundings. The way I read it is that we must therefore not try to make things with QWAN, but to try to shape our process so as to let QWAN emerge on its own.

It seems clear indeed how the founders of XP was influenced by Alexander to distrust big design up front and instead favor small iterations where the system and its architecture is allowed to emerge on its own.

With "Our Patterns Language" Alexander tries to document the patterns that already exist in our traditional towns and buildings. These are not the patterns created from the minds of a few architects, but the ones that have emerged on their own wherever buildings have been built by their users in harmony with their surroundings and their use. Alexander's patterns are not strict replicas, but recurring structures that are similar, but yet slightly different in each manifestation. He describes how each house in the Alps is similar yet different, each one being perfectly adapted to its particular location and use. In this I believe some of the QWAN lies. Beauty lies not in perfect geometric shapes or in sameness, but in the small variations on a common theme that would only make a structure beautiful in its particular location with its particular use.

For me a pattern have always been a solution to a problem that many people have faced before and solved with the same general of idea. A pattern does not need to follow the common rules of thumb of a field. It must only have been useful in solving a problem for people in the past. Indeed I remember thinking when reading design patterns that I thought some of them were a breach of certain design principles as I understood them. But that is OK because they, although the probably not the best, are good solutions to the problems they address.

Alexander thinks design patterns are important because they are the natural rules for creating beautiful structures that have emerged on their own. They are not only "... a pattern which one might or might not use ...", but they are ".. desirable pattern[s] ..." that one must create "... in order to maintain a stable and healthy world." As such Alexander regards the patterns that naturally arise when the people who are most familiar with a structure's use and location and who are familiar with how similar structures have been created build something. These builders does not sketch out every detail, but brick by brick build a structure from the mental images in their mind. It is these shared images in "a farmers mind" that are what Alexander calls patterns.

In the last excerpt a few of Alexander's patterns are presented. I must admit that I had a hard time reading them while focusing on their application in CS as my mind constantly wandered to thoughts of the places I have lived and worked an how they fit in. Even so I want to attempt to one of them to our field.

Site repair states that one should always build a structure on the parts of a land that are in worst condition. The good parts are already healthy and do not need our help. It is on the rest that we should apply ourself to improve our surroundings. In terms of software engineering I can not help thinking about the concept of technical debt. In a system there is often one component that is in a worse state than the others. Perhaps it had to be rushed in order to reach an important deadline. Or perhaps it has gradually deteriorated to a point where people dread touching it and apply great ingenuity to avoid changing its internals. Because why risk breaking something that after all does work. And why not implement that new feature which may belong in this component in another one that is cleaner and that won't break down when changed. If we were to apply site repair to this problem we should fix the part of our system that are in the worst shape. The good parts are already healthy and do not need our help. It is in the unhealthy part, and everyone will have an idea of where this is, where we can increase the healthiness of our system.

The intimacy gradient is also quite easy to apply in terms of layers, but I am curious to hear suggestions for analogies for light on two sides of every room. I suspect that there aren't really any which is fine. We can still learn from Alexanders thoughts and his description on how he uncovered the pattern, not by analytical studies, but by casually observing it wherever he went.