Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
 

Other Reviews

Some books are more famous than their authors; and some authors are more famous than their books. Christopher Alexander is in the latter category, but of all his writings, this book is perhaps the most often referenced. Alexander became the guru of the Object-Oriented software community through a mutual interest in Pattern. One may suspect that his name is bandied about by many who have not read a word by him; not wishing to fall into that category, one may note that this modest paperback of a couple of hundred pages gives plenty of clues as to Alexander's thinking.

The argument depends on what seem to be quite a small number of intellectual concepts such as form, pattern, and unselfconscious design. At least pattern and form look like large ideas. Alexander summarizes his themes in the Epilogue:

My main task has been to show that there is a deep and important underlying structural correspondence between the pattern of a problem and the process of designing a physical form which answers that problem. I believe that the great architect has in the past always been aware of the patterned similarity of problem and process, and that it is only the sense of this similarity of structure that ever led him to the design of great forms.

The same pattern is implicit in the action of the unselfconscious form-producing system, and responsible for its success. But .. because we are selfconscious, we need to make explicit maps of the problem's structure, and therefore need first to invent a conceptual framework for such maps. This is all I have tried to do."

In other words, Alexander is claiming, not that the problem shows you its own solution -- that would be too convenient! -- but that "a set of requirements, when taken together, create a new idea about what one main feature of a physical form ought to be." (p128)

He discusses with approval the example of a traffic-flow map at a junction (shades of Edward Tufte's Visual Explanations) in which the thickness of the traffic-flow arrows translates into the width of the required traffic lanes:

In this form the diagram indicates directly what form the new intersection must take. Clearly a thick arrow requires a wide street, so that the overall pattern called for emerges directly from the diagram. It is both a requirements diagram and a form diagram. This diagram is a constructive one.

The constructive diagram is the bridge between requirements and form. .. [its] duality is itself characteristic of our knowledge of form.

Well I'm not sure I can follow Alexander into his almost mystical claim of characteristic duality; the mapping between the choice of line-width for a traffic-flow diagram and road-lane width in the solution seems to be a mixture of happy accident and the human tendency to visual and physical metaphor. Does the same thing happen at all often in other domains? Do descriptions of requirements really suggest obvious solutions? Does the wish to fly quickly and safely directly suggest a plane powered by triple-shaft high-bypass gas turbines?

He also gives the example of "the now familiar one-hole kettle". (p128)

The single wide short spout embraces a number of requirements: all those which center round the problems of getting water in and out of the kettle, the problem of doing it safely without the lid's falling off, .. of making manufacture as simple as possible, .. of providing warning when the kettle boils, the need for internal maintenance.

He points out that the old design involved a spout, a hole in the top and a lid. New materials solved the problems of corrosion and cleaning, so the hole and lid became unnecessary, and "The set of requirements, once its unity is recognized, leads to a single physical component of the kettle." (p129)

Now it's true that with hindsight we can see that a one-hole kettle is an elegant solution, but is any method or "map" actually offered here? Is there anything beyond the facile argument that you should study the problem and see if you can't find an intuitive and satisfying solution? Alexander advocates "a functional decomposition of the problem" -- and along with Herbert Simon, he was certainly one of the first to do so. Unfortunately (as Jack Carroll argues), top-down functional decomposition often leads to unjustified assumptions and therefore to poor solutions. If you decide that there are four components - say, floor, walls, windows and roof - then you block yourself off from other, possibly more creative and better solutions. And certainly, in software, functional decomposition demonstrably failed as a way of identifying design elements.

So it is rather ironic that Alexander, far from being derided for the (quite sensible) suggestion to try to decompose the functions of a system, has instead been lionised for talking about patterns. Perhaps he was a convenient hook; or perhaps he was good at publicising a single big idea at a time when something new was very much wanted.

But in many ways Alexander was far ahead of his time. A set of very modern concepts concerns "a growing tendency to look for suitable scales, and to set up performance standards, for as many requirements as possible" (p98). Remember this is a third of a century before the Robertsons wrote about 'fit criteria' for their requirements, or the grey suits of New Labour started burbling about performance metrics in all aspects of government. Alexander introduces the concept of a 'misfit variable', which at its simplest "can be in one of two states: fit and misfit." Examples are affordable versus too expensive; too small versus big enough, and so on. Or, you can set up a scale and measure the quality of the fit of the proposed solution to the requirements. Happily, Alexander points out that you can't measure everything -- boredom in an exhibition, human warmth in a living room, and lack of variety in a park being easily recognisable examples of not-very-quantifiable misfit. On the other hand, capacity is simple to quantify. One wonders what Alexander would have to say about long-term service contracts that aspire to measure ambience of trains and platforms, and public jeering about rumoured requirements on pieces of litter at least 2 centimetres long.

There are plainly some important and stimulating ideas in Notes on the Synthesis of Form; at the very least, they have helped to create a large following. The book also has some significant weaknesses: in particular, it is very theoretical, being an intellectual argument rather than stemming from much practical design experience such as that of Alexander's contemporary, Henry Dreyfuss. The book has no index, which is annoying; heaps of notes at the back, and neither glossary nor bibliography, which is inconvenient.

What is worse, the style is allusive rather than explanatory. To give a concrete example:

"The Sumatran gives his roofs their special shape, not because this is structurally essential, but because this is the way to make roofs in Sumatra."

A Traditional House of the Toba Batak people, Sumatra - not from the book

The design, or form (to use an Alexandrine word) is striking and highly distinctive; the effort plainly greater than strictly necessary. What was the point that Alexander was making?

"The rigidity of tradition is at its clearest, though, in the case where builders of form are forced to work within definitely given limitations."

Well, yes, the Sumatran roof is visibly that.

"The Welshman must make the crucks which support his roof precisely according to the pattern of tradition. ...

Every one of these examples points in the same direction. Unselfconscious cultures contain, as a feature of their form-producing systems, a certain built-in fixity -- patterns of myth, tradition, and taboo which resist willful change. Form builders will only introduce changes under strong compulsion where there are powerful (and obvious) irritations in the existing forms which demand correction."

The point is much easier to consider with an example; indeed, looking at my photograph, one at once starts to wonder how long the traditional form may have existed, how fixed it was (don't you?). Without the real example, one has at best a dim mental image of the forms under discussion. Actually, there are some images of forms in the book, but they are mostly diagrams of topologies and sets, apart from the worked example in the appendix, where the illustrations are somewhat like stylized map symbols -- symbolic, possibly beautiful, but not easy to interpret.

As a book, Notes is not wholly satisfactory, but it is certainly interesting. Alexander was thinking and writing about requirements and design fully four decades ago. The book would be more convincing if it had been based on practical examples from his own experience, but the truth seems to be that he was a theoretical architect more than a practical one.

Moving to today, there are plenty of academic papers containing fine-sounding research proposals, as well as books and articles by consultants, but few pieces of experimental or even experiential (uncontrolled) evidence. It is certainly difficult to devise convincingly large-scale experiments (how do you run even two identical million-dollar projects with just one variable different?), and equally hard to get industry to report truthfully on approaches that failed (why do something that benefits the community if it harms you yourself?). But if we are going to move the requirements process on -- if not to a fully scientific then at least to an effectively empirical branch of systems engineering -- then we need to measure the success of our ideas to show they do solve problems on real projects.

Alexander represents an important strand in the history of systems thinking: the theoretical strand. His ideas are stimulating, as good intellectual work should be, and he writes elegantly and admirably clearly. But he unwittingly provides a beautiful illustration of the limits of pure reason (apologies to Kant): some things, such as engineering, are essentially practical, and just have to be tried out in practice. He should be read for these reasons.

© Ian Alexander 2003

You may also like: