The Relevance of Christopher Alexander to Destiny
Russell Holt
Draft 3 Dec 10, 1999
Draft 1 Dec 6 1999
Christopher Alexander is a controversial architect; his works "The Timelss Way of Building" and "A Pattern Language" (late 70's) still shocks architects - either making them ecstatic or outraged. He is following up this work with a four volume set he's been working on since then call "The Nature of Order" early next year.I want to begin with what Christopher Alexander is trying to do to architecture, then relate that to our situation because we're attempting to apply his ideas to the software process.
For thirty years he has been saying that modern architecture is broken. Ask yourself: do you think so? What percentage, do you think, of architecture and construction projects fail? My guess is a very small percentage. We "know" how to make buildings that stand and bridges that don't buckle and roads that don't fall apart for a while, etc.
Alexander's claim is that modern architecture creates "dead" buildings, which don't work, which make us feel terrible relative to traditional buildings which are alive and make us feel alive. He further claims that modern methods are incapable of creating such beauty. Why? We've replaced the people with abstractions. "We" design for abstracted people to abstract requirements instead of individuals with individual needs, and the entire process goes against letting the results be customized and grown over time.
For Alexander, the highest objective in architecture is creating what he calls "the quality without a name", the quality that gives a building life and makes it work. He claims that modern architectural methods are fundamentally unable to generate this quality - and this means everything from the funding process, zoning, contracting, architecture, construction, etc. The separation of architecture and construction is at the core; the architect is not builder, and the builder is not architect. We're still stuck with the Age of Reason point of view that we should seek to control nature rather than work in harmony with it. Specialization has fragmented and confused our holistic understanding of the world. Architecture is done in the abstract - requirements are gathered, design is done, and the blueprint is thrown over the wall to the construction engineers. A waterfall process if there ever was one.
Now compare this to software. What percentage of software projects fail? A huge number. But, even worse, the software that does get created is often times just plain terrible. At least buildings don't fall down that often, whether they are "alive" or not. Finally, everyone can think of examples of buildings - whether they are good or bad - and everyone can walk through them and see where the windows are, the placement of the doors, the height of the ceilings, the quality of light -- and everyone can judge whether this is good, bad, "alive" or "dead". Compared to the number of buildings and bridges we've experienced, the number of programs and software architectures we've experienced is incredibly small.
So in software, we're at a triple disadvantage to the architects. Alexander is claiming that modern architecture needs to be completely supplanted before we can regularly create buildings which are alive and which work for their inhabitants. If the analogy holds, what might this mean for the world of software?
What will it take before we have as many examples of good software as we do buildings? The public can scrutinize the failure of an architect when his bridge collapses, and everyone can learn from this failure whether professional or not. Not so with software - will it ever be the case?
The solution, in Alexander's world, is that the architect and the builder must be one. The people who ultimately live and work in the buildings must be involved. Knowledge and experience stand between ordinary people and the habitations best suited to them. Incremental and constant growth, starting small, grassroots efforts are all key themes to Alexander's view of architecture, and I think they are important lessons to us.
An Alexandrian approach may have worked in software at other times in the past, but there is no better opportunity than today because of the web. What is the web? What does it let us do?
First, the web lets us start small and grow our systems incrementally by reducing or eliminating distribution costs between increments: we can get every increment out in front of the entire customer base and feed back their ideas into the process. By doing so, we involve the actual inhabitants of the system in the process; we build something that is better suited to their needs; we create the right pieces for them in the right order. If we're not taking advantage of that simple, easy opportunity then we've already failed.
Second, architect and builder must be united because no longer can technology simply implement a business strategy - the web is driving business today. For us this means business strategy, software architecture/design and implementation must be done in a cross-functional team setting and these activities must be done in parallel as much as possible. Separate from Alexander, success comes from starting small, getting your feet wet in a first project, cycling feedback to inform and adjust a business strategy and architecture, and setting up and environment that enables one to move in new directions as the market changes, as the true customer base is discovered with our new ability to get to them more directly, and as technologies come and go.
Third, building can never stop. The world is moving fast enough that what we build today, if we stop at a well-defined point, will be obsolete sooner than we think. The startup costs associated with identifying a new project to address the new needs down the road are too great for this world. Therefore, we must seek to create and environment that supports endless incremental development. If you don't set up for constant evolution that tracks the web, you'll only end up rebuilding too little, too late.
Finally, when engagements move at a snail's pace either by design (pun intended) or by defaulting due to politics and the personalities-that-survive-the-endless-mergers syndrome, it is to our mutual benefit and risk that we take it to the next level. In a client of ours whose customers are scattering to more web-savvy competitors, whose employees form a pre-internet culture, are passive, and are divided against themselves in politics and bureacracy, is it conceivable that their traditional software process approach could result in an internet success?
What we most need in our engagements, then, is the strength and the vision and leadership to come into that environment and change it so that it can succeed. Only when the organizational culture and the process by which we build is a reflection of the environment will we be able to create systems that work.
And that is all about people.