10 Architecture Tips From "The Timeless Way of Building"

During vacation time last week, I finally sat down to really read The Timeless Way of Building by Christopher Alexander.  I had flipped through it before, but never took the time to digest it.  This is the classic book on design pattern which applies to physical buildings and towns, but remains immensely relevant to software architecture as well.  While the book can admittedly be a bit dry and philosophical at times, I also found many parts of it quite compelling and thought I’d share 10 of my favorite points from the book.

1. “… We have come to think of buildings, even towns as ‘creations’ — again thought out, conceived entire, designed … All this has defined the task of creation, or design, as a huge task, in which something gigantic is brought to birth, suddenly in a single act … Imagine, by contrast, a system of simple rules, not complicated, patiently applied, until they gradually form a thing … The mastery of what is made does not lie in the depths of some impenetrable ego; it lies, instead in the simple mastery of the steps in the process …” (p.161-162)  He considers architecture as the mastery of the definition and application of a standard set of steps and patterns to construct solutions.  We don’t start with a blank slate or have to just burp out a complete solution — we start with knowledge of patterns and experience and use those to put together a viable solution.
2. “Your power to create a building is limited entirely by the rules you happen to have in your language now … He does not have time to think about it from scratch … He is faced with the need to act, he has to act fast.” (p.204)  You can only architect things based on the patterns in your vocabulary.  All the more reason to constantly seek out new ideas and bolster the collection of experiences to work with.
3. “An architect’s power also comes from his capacity to observe the relationships which really matter — the ones which are deep, profound, the ones which do the work.” (p. 218)  The skill of observation and prioritization is critical and this highlights what will make an architect successful or not.  We have to focus on the key solution aspects and not get caught in the weeds for too long.
4. “A man who knows how to build has observed hundreds of rooms and has finally understood the ‘secret’ of making a room with beautiful proportions … It may have taken years of observation for him to finally understand …” (p. 222).  This is the fact that most of us hate to hear.  No amount of reading or studying can make up for good ol’ fashion experience.  All the more reason to constantly seek out new experiences and expect that our inevitable failures along the way help us use better judgement in the future.
5. “The central task of ‘architecture’ is the creation of a single, shared, evolving, pattern language, which everyone contributes to, and everyone can use.” (p. 241)  Alexander is big on not making architecture such a specialty that only a select few can do it well.  Evangelism of what we learn is vital for group success.
6. “To make the pattern really useful, we must define the exact range of contexts where the stated problem occurs, and where this particular solution to the problem is appropriate.” (p. 253).  It’s sometimes tempting to rely on a favorite pattern or worse, just use particular patterns for the heck of it.  We need to keep our core problem in mind and look to use the most efficient solution and not the one that is simply the most interesting to us.  
7. “If you can’t draw a diagram of it, it isn’t a pattern.” (p. 267)  Ah, the value of modeling.  I’ve really gained a lot of value by learning UML over the past few years.  For all its warts, UML still provides me a way to diagram a concept/pattern/solution and know that my colleagues can instantly follow my point (assuming I build a competent diagram).
8. “Conventional wisdom says that a building cannot be designed, in sequence, step by step … Sequences are bad if they are the wrong sequences.” (p. 382-383)  The focus here is that your design sequence should start with the dominant, primary features first (broad architecture) and move down to the secondary features (detailed architecture).  I shouldn’t design the elevator shaft until I know the shape of the building. Don’t get caught designing a low level feature first until you have perspective of the entire design.
9. “A group of people who use a common pattern language can make a design together just as well as a single person can within his mind.” (p. 432)  This is one of the key points of the book.  When you put folks on the same page and they can converse in a common language, you drastically increase efficiency and allow the team to work in a complimentary fashion.
10. “Each building when it is first built, is an attempt to make a self-maintaining whole configuration … But our predictions are invariably wrong … It is therefore necessary to keep changing the buildings, according to the real events which actually happen there.” (p. 479-480) The last portion of the book drives home that fact that no building  (software application) is ever perfect.  We shouldn’t look down on “repair” but instead see it as a way to continually mature what we’ve built and apply what we’ve learned along they way.

For a book that came out in 1979, those are some pretty applicable ideas to chew on.  Designing software is definitely part art and part science and it takes years of experience to build up the confidence that you are building something in the “right” way.  If you get the chance, pick the book up and read some of the best early thinking on the topic.