In my last journal entry I found it difficult to summarize what Alexander meant by the "quality without a name" because he expresses the idea so well himself, and the idea (by definition) kind of defies description. The same can be said for the second part of the Timeless Way of Building entitled "The Gate". This section of the book outlines the idea of a pattern language, which is the main ingredient in creating places, buildings, towns (software perhaps) which have the quality without a name. He does such a masterful job at describing what a pattern language is, that it is hard to review it here...but here it goes anyway.
The basic idea is that during the act of building a builder will assemble component pieces to create a new work. These component pieces are themselves made up of component pieces. The new work is itself just a part of a larger whole, which is being built in components. The components and their relationships together make up the patterns of a 'pattern language', which is shared by a community of builders. These components or elements of the language can include both physical objects (town square, religious center, main street), and also events that take place in these places (markets, weddings, walking). In fact the places and events are inextricably bound together. The 'pattern language' is the complete set of options that a builder has available when building. The languages vary from place to place, time period from time period. And as you might expect pattern languages aren't always used explicitly, but are often used implicitly all the time by builders. Choices are always made, patterns are copied from various places, and are incorporated in new ways. Most importantly some patterns (and hency pattern languages) are able to generate and sustain life, and others which inhibit and end up destroying life.
This is where things get interesting, the difference which makes a pattern (and the language it is a part of) alive. Alexander argues that the specialization which makes much of modern life possible also encourages a dislocation in the components of a pattern language:
If I build a fireplace for myself, it is natural for me to make a place to put the wood, a corner to sit it, a mantel wide enough to put things on, an opening which lets fire draw.It's extremely important that patterns remain useful and rooted to their purpose, or else they risk becoming abstracted, useless and dead.
But, if I design fireplaces for other people--not for myself--then I never have to build a fire in the fireplaces I design. Gradually my ideas become more and more influenced by style, and shape, and crazy notions--my feeling for the simple business of making fire leaves the fireplace altogether.
So, it is inevitable that as the work of building passes into the hands of specialists, the patterns which they use beocme more and more banal, more willful, and less anchored in reality.
Another point Alexander makes reminded me of the Perl philosophy, and open source in general, since pattern languages must be shared if they are to be alive.
The acts of design which have been thought of as central are acts which use the structure already present in these underlying languages to generate the structure of specific buildings.
In this view, it is the structure of the underlying language which is doing most of the hard work. If you want to influence the structure of your town, you must help to change the underlying languages. It is useless to be innovative in an individual building, or an individual plan, if this innovation dos not become part of a living pattern language which everyone can use.
And we may conclude, even more strongly, that the central task of 'architecture' is the creation of a single, shared, evolving, pattern language, which everyone contributes to, and everyone can use.
Alexander goes on to outline how to explicitly describe a pattern as a rule so that it may be shared. Essentially, all patterns have the form:
Context --> System of Forces --> ConfigurationWhere context is the arena in which the pattern operates, the system of forces is the dynamic which the pattern is attempting to resolve, and the configuration is the resolution to the conflict. This method of description will make more sense if you read the book. It's not really relevant, but I couldn't help but be reminded of the idea of a tuple in RDF where each statement has the form:
Resource -> Property -> ValueI think this is because I'm enjoying O'Reilly's new RDF book at the moment too :-) At any rate after Alexander provides details about how to describe a pattern it is very clear what he means by it. He stresses that it is hard work finding these deep life sustaining patterns, but he provides instructions on how to go about it. What's more these instructions use architecture as the model, but they seem to abstract so well to software development. It's no wonder that this book inspired others too look for patterns in software. In building construction patterns had been shared implicitly for a long time, but the specialization and professionalization of architecture have lead to these patterns being dropped in favor of ones that could be expressed as blueprints etc. What's more these blueprints are guarded as business secrets, and are not shared. All this leads to a breakdown in the patterns, and the overarching pattern language that they make up. The process of discovering and sharing patterns in an unambiguous way is a technique for countering this trend. "The Gate" was every bit as fascinating as "The Quality", and I've still got one more section to go...up next "The Way".
