"The Timeless Way of Building", patterns, architecture, and software
Posted by rick Mon, 05 Jun 2006 03:27:00 GMT
I mentioned earlier that I’ve been reading Christopher Alexander’s The Timeless Way of Building (TWoB hereafter). I finally finished it this morning after N months of reading on it. On the one hand I’m just like that: I’ll have 5+ (or 10+) books lying around open and partly read for months at a time, meaning that nothing really gets read quickly. On the other hand, I think TWoB deserves a slow and considered reading, and that’s how I approached the book.
TWoB is, on the surface, a book about architecture. It even says so in the title. It’s author is a well-known architect (still living, even, as far as I know). With its two sequels (A Pattern Language and The Oregon Experiment ) it has, however, caused quite a stir in another field—that of software development. TWoB was published in 1979, after 14 years of effort, so we’re now over 40 years from its inception.
In 1995 the so-called “Gang of Four” (GoF) text Design Patterns: Elements of Reusable Object-Oriented Software was published. Inspired by Alexander’s work on pattern languages for building, the authors (and their collaborators) brought “patterns” and pattern languages to computer software. Since that time the adoption of patterns in the software community as both paradigm and panacea has been rapid and widespread. A simple search for pattern-titled books on software in any decent library, or on web stores such as Amazon will produce a dizzying array of results. There are design patterns, analysis patterns, configuration patterns, integration patterns, deployment patterns, you name it. There are publishers who appear to believe that no book should be printed for consumption by software developers (and their management cousins) unless the word “patterns” appears on both cover and spine. There are job applicants going to interviews who know the 23 patterns in GoF by heart, speak them like some sort of creole dialect, and couldn’t code their way out of a soggy paper sack.
As a long-time software developer (ok, I never used a punch card, but I’ve been around long enough to know the following…) I can readily say that ours is an industry beset by marketers, marketroids, buzzwords, acronyms, predatory vendors, incompetence and an infinite amount of hype. As an industry our tools are mostly broken, our projects mostly failures, our memories systemically too short, and our confidence mostly beyond our abilities. Not only do we almost never have a solid gauge on how competent we (ourselves) are at what we do, it seems that everyone outside our profession is even worse at judging our competence. Not only are many programmers better suited (for the benefit of both those near to them and those working in our field at large) at doing lawn work or, better yet, washing dishes at restaurants where the health department doesn’t inspect very often; but mind-bogglingly destructive practices are promoted as “best” practices on the backs of the opinions of vocal better-off-washing-dishes incompetents and unscrupulous vendors willing to sell any buzzword or acryonym so long as the slogan is heard wide and the coffers are filled deep.
Into this dire ecosystem some decade ago was launched a good-intentioned campaign to bring Alexander’s brilliant insights (and after combing through just one of his many texts, I believe Mr. Alexander has earned the descriptive “genius”) into the industry of software development. Having read a number of discussions of how influenced the GoF were by Alexander’s pattern languages, and how good their intentions, I truly believe they believed they were doing the industry a great service. I think they may have even done so. If you catch a contradictory tone here (or a hesitance) though, it’s because I don’t believe we have seen that service yet bear fruit. Worse, I have my doubts it ever will.
While reading TWoB I was repeatedly struck by how powerful the authors concepts were, how clearly they were related, how inevitably the Good followed from his observations and suggestions. I was drawn back repeatedly to the realization that there were so many parallels between software and architecture. I was truly compelled by his invocation of Taoist principles, his explanation of the Quality Without a Name, and that quality’s inevitability: as a consequence of breathing life into a building, a community, a town.
Alexander exposed systematically the problems resulting from our modern methods of industrial, methodical, mechanical construction of not just our buildings but our lifestyles. He digs deep into the living way to build, to live, that all of us instantly recognize when we see it. He drew in the foundations of Eastern philiosophies. He shows a way back, through a simplifying and life-giving formalism (the pattern language) to the practice of building and living in a manner that is whole and alive, The Way that is timeless, which infuses our surroundings with the Quality Without a Name, which ultimately releases us from the need for the pattern language itself and returns us to the natural way of living and building which balances the forces around us and simplifies life and happiness.
Looking from his viewpoint back into the past decade of pattern-inspired software development I see that “pattern” has become just a replacement word for the (abysmal and soul-sucking) marketroid buzzword “best practice”. A pattern is something you’ve done at least twice, or something that someone smarter (or richer, or more cutting-edge) says you ought to be using instead of solving problems on your own. “Just show me the patterns I need to know”, says the lazy developer, “and don’t make me learn all that other nonsense.”
Even the inspired writing on patterns for software has hit at such a narrow scope and has left behind the core, the foundation, of what makes Alexander’s work so compelling, so powerful. Alexander’s patterns were a way of summarizing and exposing living techniques for those who could recognize them, but who had been robbed of their innate knowledge of those techniques by the distracting and numbing systems of modernity. In a tiny way the patterns were a shorthand, but more importantly they are a temporary crutch to be used to escape the paradoxes and failures of modern systems (which produce buildings, communities, and lives without the Quality Without a Name) and to return to our basic living understanding of how to make living places that are perfectly adapted to their environment and the problems they face.
What was brought over was stripped completely of Alexander’s core, stripped of purpose, and converted to a set of tiny rules showing common techniques for handling tiny problems. Where Alexander’s patterns cover concepts from the scale of individual windows up through the process of constructing a living neighborhood, covering also patterns of repair; software patterns, where they are helpful at all, are mired at the level of the window pane.
Even these are contentious. The simple and common “Singleton” pattern from the GoF book is the subject of much chest-thumping and vitriol these days. If such a simple pattern cannot even be agreed to be “good” or “alive” or to encourage the Quality Without a Name I wonder what software “patterns” could.
At one point in TWoB Alexander writes:
In short, a building laid out by a pattern language process, and which comes to life because of it, will die again, quite certainly, when it is built, unless the process of construction is the same—unless, that is, the same spirit which generated rooms that are just right, entrances where they should be, light coming from the right directions . . . is carried on into the details, and also shapes the columns, and the beams, the window frames, the doors, the vaults, the colors and the ornament as well.
And what strikes me is that Alexander’s pattern language is so far reaching that only the tiniest part of it deals with those details of construction (windows and columns and doors, etc.), otherwise dealing with all the powerful layers above these. These other tiny patterns are indeed important, but so as well is this other final once-omitted piece: the patterns of the process of building. In software we have, with a few tiny exceptions (I would include Martin Fowler’s Analysis Patterns book in this area, which addresses a slightly higher-level set of patterns that sometimes feel as if they could generate the Quality Without a Name in a software system) only patterns about nails and window pains and door knobs. We have nothing about building down from the higher levels, always ensuring we first make something living. We have nothing, really, about the process of construction, or the process of repair, that fits with Alexander’s core drive, that produces systems and interactions that are alive.
We have continued in the business of making dead systems, while deluding ourselves into thinking we have learned something that could make a thing that is living.
At the risk of having Amazon sue me for grabbing one of their reviews (go ahead and sue me), here’s one of the many reviews of the GoF book:
My only critique of the book is that it is very heavy on examples. It is all relevant and if you have the time to read and digest it all you will be a better programmer. However, there are more consice books that do a better job of distilling the important concepts of design patterns and books that provide better modern approachs. This is the type of book that you have to read in school becuase it is a classic. I would equate to classic literature like Homer or War and Peace. They are important in a scholarly sense if you wants a deep historic understanding of the topic. However, you can understand and use design patterns without reading other books and you will save a lot of time.Another good analogy is the way calculus is taught in school. First they teach you in-depth complicated way. They take you through all the steps the inventor went through to come up with it. Then they show you the short cuts that are used in common practice. You have a better understanding of the topic because you know the hard way but you would be foolish not use the short cuts.
So you can read this book and get an indepth understanding or you can skip this step and go straight the a consice book that shows you how patterns are used practically today.
(source)
In one sense a perfectly reasonable review, if you’re sitting out in cubicle land looking for a book that will get your head above water with whatever the important thing is you Must Know to stay afloat in a hyper-competitive industry. Replace the subject matter (design patterns) with any other modern buzzword or “best practice”, say XML, JSP, CSS, Unit Testing, Continuous Integration, Behavior-Driven Development, JMX, Ruby on Rails, etc., etc., etc.; and you could publish that review 500 times and have people give it 4- and 5-star ratings. Buy that book, or become unemployable.
Pretty dismal, sure, but them’s the breaks. Only, after reading the primary source, it’s truly depressing. 90%+ of TWoB was pure Eastern philosophy. The book was primarily about how languages of patterns exist already in the world, have existed since the beginning of society. They are visible in the oldest and newest buildings and towns that are “living”, not “dead”. Alexander had been looking for The Way to build something alive, and spent 14 years writing this first volume to help communicate it. It’s powerful. The book is essentially about the Tao and a way we can practically shrug off the blinding layers of automated and modernized living and building to get back to the Tao.
The only thing that carries over to software development though is the smallest and weakest part of the “crutch”. The Tao is left behind. The Way is not here.
It is clear in reading TWoB that a pattern language which is not driven by the need to make something that is alive, that is the best that it can be, will be incapable of making anything at all that is alive. Even missing a single important step will result in the realization of a living design which is itself dead.
It is obvious to me now that, despite it’s seeming inevitable proliferation, that the software “patterns” movement is stillborn. In its best moments it uncovers a few nodes in the lower reaches of the graph of a useful pattern language, which appears doomed to never reach the important upper reaches where it could ever result in a living system. Otherwise, this “movement” is mostly a vehicle for buzzword proliferation, a hook onto which tireless unscrupulous vendors hawk the next beta release of snake oil, a veil behind which hides laziness and confusion masquerading as work and knowledge.
If I seem a bit jaded or cynical, perhaps I am. But it’s really aggravating to see all the sound and fury dedicated to “improving” the horrid state of software development and realize that the vast bulk of it really does signify nothing. Patterns are worthless if they are adopted without any of the important fundamentals that could ever make them “work”. Calling what passes for patterns in software “patterns” is actually insulting to Alexander, and tangentially, to anyone who has ever built something which has the Quality Without a Name.
This is not an attempt to insult the Gang of Four and their comrades who wished, and worked, to bring Alexander’s insights across the border into our field. On the one hand, perhaps what they were trying to do is impossible. On the other, they surely knew they were beset on all sides by wolves: the wolf of incompetence, the wolf of capitalism, the wolf of undisciplined practitioners, the wolf of Good Enough, . . . the pack goes on.
There has never been a software system built which comes near to having that Quality. In the direction we’re headed I can’t see that any such system will ever be built.
Is it possible to build software that is “alive”, that has the Quality Without a Name?
I can’t be sure, clearly. I’ve been thinking about this for months, the duration of the time spent reading TWoB, and may well think about it for 14 years as Alexander did, and perhaps the full 41 years it took to get us from that book’s inception to know. And I probably will still not have an answer by then.
Regardless, it will take more than replacing “best practice” with “pattern”.
We don’t have, as a species, the history in software that we have with building. Software is in some fundamental ways different from building: software is all design, the building must be part of the design process (sorry waterfall proponents, but this much has become clear in the past decade); software is malleable, like clay rather than stone, and we know that, for some real value of Good that Good software stays this way; that we know so much less about software; that software is complex like mathematics, in ways that physical things like buildings cannot be; that software doesn’t wear out, but that software can run only so long as the world supports the way it runs; that people don’t sit inside software and read a book; that people don’t look at software (at least not yet) and have clear feelings about it; that software is more destructively dominated by fashion than even architecture; that tools which are themselves destructive to building whole and living systems are often championed as The One True Way to build a system. Let me stop before I start enumerating the languages and tools which have done so much to so many for so long, sucking the very hope of life out of systems and developers alike.
Where industrial techniques are the enemy of living architecture, software development is, at this point in time, only willing to think of industrial techniques. From where I sit this forecloses the possibility of The Quality Without a Name from software. Without this, why bother with “patterns” at all?
The only thing positive I suppose I can say at this point is that any attempt to build living systems in software is most likely to come from a small group who work long years on building systems in a way that mirrors the way we build living homes and communities. Perhaps someone will gain insights like Alexander’s and still have the time to share them with us. Perhaps some of us will have the sense to listen.
