“The Quality Without A Name” is a phrase coined by Christopher Alexander in The Timeless Way of Building to describe the feeling of satisfaction and contentment engendered by good building. He later went on to call it ‘life’, but a friend of mine described it as ‘The Tao of Building’, which seems rather appropriate too. The Timeless Way of Building is a fantastic, if somewhat overwritten book, introducing Alexander’s themes and ideas about how modern architects and builders can recapture the qualities inherent in great (usually old) buildings.

Alexander later went on to crystallise his ideas about how

to lay out cities, towns, neighbourhoods, houses, rooms, windows, etc. in his massively influential book, A Pattern Language, in which Alexander and his co-authors attempted to set down a ‘language’ that would enable anyone to design and build somewhere that possessed the Quality Without a Name for themselves. Sadly, as they admit later, they failed in this attempt; efforts to use this pattern language by laymen resulted in interesting, but flawed, buildings. Despite the failure (in Alexander’s terms) it’s a great book; the prose can be a little annoying at times, but the analysis is deep, and mind-changing.

Here’s an extract from one of the patterns:

208. Gradual Stiffening

The Fundamental philosophy behind the use of pattern languages in buildings is that buildings should be uniquely adapted to individual needs and sites; and that the plans of buildings should be rather loose and fluid, in order to accommodate these subtleties.

[An essay describing the problem more fully, and the reasoning behind the solution presented]

Therefore:

Recognize that you are not assembling a building from components like an erector set, but that you are instead weaving a structure which starts out globally complete, but flimsy; then gradually making it stiffer buit still rather flimsy; and only finally making it completely stiff and strong.

We believe that in our own time, the most natural version of this process is to put up a shell of sheet materials, and then to make it fully strong by filling it with compressive fill.

Look, Agile Building!

Alexander and his co-authors have found a powerful way of managing complexity by isolating parts of the process of building to individual patterns, but neatly tying them into the greater whole by their use of introductory and closing paragraphs to explain the context to which the pattern applies. When I read it, I find I’m constantly flipping back and forth to look at these contextual patterns that support (or use) the pattern that I’m concentrating on. The book itself has the Quality Without a Name.

It was only after I’d read The Timeless Way… and A Pattern Language that I came across the idea of Design Patterns in programming when a friend lent me the Gang of Four’s Design Patterns.

I don’t really like Design Patterns. Too many of the patterns seem to be concerned with working around problems with the static nature of C++ and Java—not exactly useful if you’re used to a more dynamic OO language. Another, deeper failing, is the disjointed nature of the patterns presented; there’s no attempt to tie the patterns together in a coherent language and the whole thing feels like a mishmash of ideas waiting to be turned into a finished book.

There is one software patterns book I’ve read that gets it though, that has The Quality Without A Name in the same way that A Pattern Language does. That book is Smalltalk Best Practice Patterns by Kent Beck. If you don’t know Smalltalk, don’t be put off by that title though. Most of the patterns in the book can be applied directly to any suitably dynamic OO language (Perl, Python, Perl 6, Javascript…) and the syntax of Smalltalk is virtually nonexistent and easy enough to pick up.

The book works well because Beck, quite deliberately, limits its scope to the “tactics” of coding. Instead of going for the big things, we’re dealing with the nuts and bolts: how to choose good names, how to write methods in ways that encourage reuse and flexibility, how to keep things loosely coupled. Beck explains this stuff with concrete examples and simple rules, that work phenomenally well together. It’s hard to put my finger on why it works so well, but my gut feeling is that it’s because Beck has not forgotten the importance of context.

Very few of the patterns are strictly standalone, they refer to each other up and down the ‘levels’ of the various patterns and the individual patterns are small enough, and well enough supported by the other patterns in the language that they remain tightly focussed on the issue they address.

Smalltalk Best Practice Patterns is a complete pattern language, something that I’ve not seen achieved in any other software patterns book (though Martin Fowler’s Refactoring: Improving the Design of Existing Code gets pretty close.) It’s easy to read; full of practical wisdom from someone who knows their stuff and can explain it well.

I recommend this book wholeheartedly to anyone who wants to become a better programmer, and especially to anyone who does object oriented programming in a dynamic language of any kind. If you find me in a bar amongst programmers, and we’re talking about how to get better at our craft, then I’ll almost certainly be banging on about how good this book is.

I believe the Java types are fans too, but if I were a java programmer then I’d find the kind of flexibility inherent in Smalltalk as expressed in this book would just make me want to abandon Java in favour of something more expressive.