Many moons ago I started reading A Pattern Language by Christopher Alexander et al. This is widely regarded as the book which started the present `design patterns' fad, but it is not about `software architecture'. Anyway, with a library deadline looming, I finally finished it....
A Pattern Language -- some sort of review
This is a book about the design and construction of towns and buildings -- what it is now fashionable to call `the built environment'. Alexander et al. proceed from the reasonable ideas that
- particular solutions to particular problems recur in architecture;
- people innately recognise and remember these solutions.
They call a class of problem and its solution a `pattern' and A Pattern Language is a dictionary of these patterns. Each definition identifies a perceived problem, discusses it, and offers solutions (which give the patterns their names). Other related patterns are identified. The dictionary covers artefacts of every scale, from countries to cupboards; the patterns are listed in inverse order of the size of thing to which they apply.
(The dictionary itself would be a perfect application for hypertext, and it is sad that it is not freely available on the web. There is a paid service, though.)
The book was published -- following extensive experimentation by its authors and in conjunction with two other books, The Timeless Way of Building and The Oregon Experiment -- in 1977; its outlook is, perhaps, characteristic of its time. Today, some of the prescriptions Alexander et al. give seem naive or outmoded. For instance, given the general problem that: (pattern 80, `Self-governing workshops and offices')
No one enjoys his work if he is a cog in a machine,
they suggest that employees work only in
... self-governing workshops and offices of 5 to 20 workers. Make each group autonomous -- with respect to organisation, style, relation to other groups, hiring and firing, work schedule. Where the work is complicated and requires larger organisations, several of these work groups can federate and cooperate to produce complex artifacts and services.
An appealing thought, perhaps -- depending on what you think of your current colleagues. I don't know whether this looked more realistic in 1977 than it does today. Likewise, Alexander et al. place tremendous and unfashionable faith in centralised economic planning, as in pattern 19, `Web of Shopping', where they try to solve the problem that
Shops rarely place themselves in those positions which best serve the people's needs, and also guarantee their own stability
-- this is followed by a discussion of Hotelling's problem, which tells us that two businesses competing for custom in the same area will be neighbours, because the first's calculation of the ideal location holds good for the second, too. (This is why you often see McDonald's, Burger King and Kentucky Fried Chicken outlets in a row on the high street.) A Pattern Language argues that it is `better' for the businesses to locate separately, each in its own catchment area, and the suggested solution implies that a planner will decide where shops will go. This idea is a little attractive, but the popularity of supermarkets -- despised by Alexander et al. -- suggests that the attraction is not general.
But the patterns are generally thought-provoking, and disagreeing with a few of the arguments does not invalidate the rest any more than one would reject a dictionary because of a few objections to the definitions presented. The reasoning of Alexander et al. is based upon a variety of sources; often, they refer to psychological studies, but most of the patterns incorporate value judgments based on their own experience. Philip Greenspun writes that
this book has more wisdom about psychology, anthropology, and sociology than any other that I've read
-- and I'd probably agree, with the proviso that I don't often read books about psychology, anthropology or sociology.
The value judgments are refreshing. For instance, pattern 94, `Sleeping in public'--
It is a mark of success in a park, public lobby or a porch when people can come there and fall asleep
-- is unlikely to find much sympathy with today's legislators.
On a more general note, A Pattern Language recommends that builders construct buildings from (pattern 207, `Good materials')
only biodegradable, low energy consuming materials, which are easy to cut and modify on site....
They suggest lightweight concrete, earth, brick and tile; they recommend against any metals, wood as a structural material, and most synthetics. This is accompanied by one of those Limits to Growth type graphs of the time left until we run out of certain metals -- like iron! (About 50 years left, they think....)
Their vision of how to build is very low-tech: they recommend that structures be built entirely in compression, with no more than four storeys, and that they need not -- and, to be `human', should not -- be built exactly to measure from a plan. There's an implicit assumption that everyone should build their own house, which is a romantic if hardly practical idea.
The thesis of A Pattern Language is appealing. Of course, I say this partly because I am sympathetic to many of their prescriptions, particularly those involving urban transport--
It is clear, then, that pedestrians will feel comfortable, powerful, safe and free in their movements when the walks they walk on are both wide enough to keep the people well away from the cars, and high enough for them to drive up on them by accident.
... What is the right height for a raised walk? Our experiments suggest that pedestrians begin to feel secure when they are about 18 inches above the cars....
(As an aside, note that the book employs, in the usual US style, imperial units throughout. It is a truism that these units are more `intuitive' -- by which we mean `easier to relate to'. And I feel this even having had a purely metric education.)
I would like to live in a house designed according to the principles which A Pattern Language recommends, though I would be more wary of living in a country or economy built from the patterns. Of the various buildings I've lived in over the past few years, it's fairly clear that the ones which worked best socially followed its patterns more closely than the modern buildings which Alexander et al. identify as socially dead. Almost all of the patterns suggested for building interiors could usefully be applied to my flat, which is in serious need of a redesign.
I don't know how useful this book is to actual architects. Do they need a book to tell them that there are familiar ways to design bits of buildings? I don't know. But it's made me pay more attention to the world around me.
When, months ago, I started reading this book -- as, essentially, a dictionary, it is not an easy book to read end-to-end -- I was interested in the origins of the `design patterns' idea in programming. Reading A Pattern Language has made me much less interested in the design of software and much more interested in the design of towns and buildings.
As for `design patterns' in software....
It is probably fair to trace to Alexander et al. one of the more irritating habits of the software `design patterns' crowd: the elevation of Pattern (capitalised, emphasised, stripped of article) to the design pantheon. But we obviously cannot blame A Pattern Language for their pretentious Java twaddle or tiresome preaching.
I recommend that you do not read this book to find out about `software engineering'. It is much more interesting than that.