The Timeless Way of Building

I found this book so mesmerizing that I read it twice. During the first pass, I was surprised that the book was so philosophical and poetic in describing architecture. I expected something more technical. Later during the second pass, my goal was to find derivatives and analogies in software architecture. Based on what I found, I think every software architect would enjoy this book.The writing style that I noticed in my first read of the book made me feel like I was reading an architecture bible. I hesitate to describe the book as religious, but the book's description "the power to make buildings beautiful lies in each of us already" and the description of the word "alive" giving architecture "the quality without a name" triggered an epiphany when recalling that the Bible says "In the beginning God created the heaven and the earth." and, "So God created man in his own image." This is why I'd say this book has a primal, sacred aspect, and this is why we like to build. Additionally, the book especially moved me so my mind's eye was opened to see "alive" patterns and to think about the morphology of architecture filling voids and generating towns.On the second pass of reading, I was struck by this software architecture analogy in the table of contents: "16. Once we have understood how to discover individual patterns which are alive, we may then make a language for ourselves for any building task we face. The structure of the language is created by the network of connections among individual patterns: and the language lives, or not, as a totality, to the degree these patterns form a whole." Could this be the guidebook for designing enterprise software architecture?Obviously this book was the inspiration for the philosophy and vocabulary for software architecture, and I thought some of the following excerpts were noteworthy paradigm shifts."The patterns are not just patterns of relationships, but patterns of relationships among other smaller patterns, which themselves have still other patterns hooking them together---and we see finally, that the world is entirely made of all these interhooking, interlocking nonmaterial patterns." This sounds like the difference between patterns of software architecture and object-oriented software design patterns."Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution." Deja vu for software patterns."You may be afraid that the design won't work if you take just one pattern at a time...There is no reason to be timid...The order of the language will make sure that it is possible." Likewise in software architecture design, as one design pattern is considered at a time to see how it fits needs into the large picture of design. If this pattern is later deemed to be dead, it can be replaced by an "alive" design pattern."Next, several acts of building, each one done to repair and magnify the product of the previous acts, will slowly generate a larger and more complex whole than any single act can generate." This correlates to software refactoring."It is essential, therefore, that the builder build only from rough drawings: and that he carry out the detailed patterns from the drawings according to the processes given by the pattern language in his mind." When I read this, I thought about the metaphor to the software architect's vision and design. The software architect's design needs to be abstract enough to accommodate change easily, but yet simple enough so software programmers can understand it, finish the detailed component design and build the component to fit the architectural whole.

The concrete examples are there, but you have to wait for them sometimes.Alexander's method frees architecture from the prison of professional jargon and technical terminology. Buildings should be designed with the use in mind. What events, human or non-human will most often occur? Design should encourage the fullest expression of these events.Chapters 1-10 outline Alexander's whole philosophy of language, when perhaps it would have been more effective to give more specific examples. But the examples do come, good ones too.One he gives is that of a fountain. Should a fountain within a secluded garden have a trickle of water that spreads outward in four directions from the center? Or would a gushing flow be better? Thinking about intellectually likely tells us nothing, but anyone who experiences the two will instantly prefer the gush to the trickle. It is the feeling of freedom and aliveness. All architecture should seek to promote such a quality in the events that recur there.Another good example comes on page 300 when he talks about building houses in Peru. He was criticized for wanting to put in an "Entrance Transition" room that would allow guests to experience a change in surroundings from the formal street to the comfort of a home. Most considered this room totally unnecessary, with an attitude that "people should be beyond such trivialities." A good architect moves beyond values when designing. It is authentic feelings that are important, that must be taken into account when designing, not our opinions about how things ought to be.A complete pattern language for a building is one that recognizes all the authentic feelings that recur in and around the building. These smaller components make up the larger components that guide the decisions of the architect. Alexander's vision is insightful and well worth the look.

i'm a software designer/developer and was referred to this book by a colleague (a senior architect that i have a lot of respect for.) I finished reading a few months ago and the main impression that lingers is how much i loved the way alexander talked about the implicit goal we have when we're building things: to accomplish something "wonderful." that's my own verbiage, and by "wonderful" I mean something that endures, that humans want to interact with, and that achieves the goal you originally set out to design a solution for. in software, that's something maintainable that's easy to extend and understand and that is well thought out and well intended for the problem at hand.if you're an aspiring software architect, you would do the community around you a big favor by perpetuating this book - the more of us that speak and understand the "pattern languages" that pervade this book (and his other related works), the more we can build and aspire to build really really awesome stuff.

I bought all three books in this series, and was hoping they would help me design our new house. The first book in the series was really hard to get through. I skipped over all the parts that didn't relate specifically to a house (i.e., anything related to designing towns), and almost gave up a few times. But after a few chapters I started to "get it" and could begin to understand the concept he was trying to convey, and suddenly I could see in the pictures included in the book exactly what he was talking about. It helped me get the mindset I needed to start on the next book on patterns.