Applying design patterns unconsciously 1
I just realised something about the workings of new style Typo Sidebars: it’s just an application of the Parameter Object design pattern; the render_sidebar helper method takes a Sidebar parameter object and produces a chunk of HTML. The fact that we persist the parameter object using ActiveRecord is almost beside the point – the persistence is more important to the render_sidebars method than anything else.
Old style sidebars couldn’t really be called an application of any design pattern. Maybe that’s what bugged me about them, they lacked the Quality Without a Name. I’m not sure that the new sidebar architecture has the Quality either, but it’s much nearer to having it.
When I was learning to play Go someone told me that it’s easier to remember professional games than those of amateurs because the moves in a professional game are generally more ‘right’ than those of weaker players. To a good go player, the ‘right’ move has an obvious purpose (or, more likely, purposes). Bad moves don’t.
Maybe something similar applies to code. In good code it’s clear what each piece does – maybe it can be seen as an example of a design pattern, maybe not – and the pieces relate well to each other. In bad code, the intent and relationships are muddied.
Do Design Patterns Help?
Continuing the Go analogy, Design patterns can be likened to joseki – ‘standard’ patterns of good play in the opening of the game. It’s useful to know them, but what’s really important, and what takes time, practice and deep study to get good at, is using and adapting them well in the fuseki – the opening and its wider context. You can play a ‘perfect’ joseki in one little corner, but its influence radiates across the board and if you don’t pay attention to what that influence is and use or adapt it well, you’re screwed.
I think the analogy to the use of design patterns in programming is fairly obvious. Don’t you?
'Extreme Building'
Our experience as contractors, engineers and architects during the last 15 years has proved one thing over and over again: The things placed on drawings are inevitably – always – wrong in many particulars. Drawings serve as an important rough sketch of something that will be built, but must be executed with constant attention to room shape, light, wall and ceiling detail, openings – above all to the feelings which arise in each place, in the construction, as it is taking shape. These feelings are too complicated to predict and cannot be predicted. When a building is built from plans that are conceived on the drawing board and then simply built, the result is sterile at best – silly most of the time – and sometimes unthinkably bad. This is something familiar in virtually all large buildings that have been built since 1950. It is inevitable, given the process of construction used to build them. And it is inevitable that this process must lead to unsatisfactory results.
—Christopher Alexander, Gary Black & Miyoko Tsutsui The Mary Rose Museum
Another installment in my ongoing series of reviews of books that Amazon will take an age to deliver.
The Mary Rose Museum is an account of the Center for Environmental Structure’s bid to build a museum around the Mary Rose, Henry VIII’s flagship, which, in 1545 unaccountably sank in calm seas, in the sight of the King himself1 with the loss of nearly 700 men. The story of how the wreck was found, raised and conserved is pretty impressive in itself. I can remember watching BBC specials on the process as it was happening and being amazed at the dedication/insanity of those involved, but that’s not really what Alexander’s book is about.
In 1991, Christopher Alexander was in conversation with Prince Charles (whose interest in architecture is (in)famous). They were lamenting the then design for a museum to be built over where the Mary Rose still lies beneath a huge tent, continuously sprayed with a cold mist of water to prevent any decay of the timbers. The proposed design was for yet another anonymous hangar-like structure at odds with the other buildings in the Portsmouth Naval Dockyard, and not exactly sympathetic to either the Mary Rose or HMS Victory which sits in a nearby dry dock. The Prince sketched (probably not on a fag packet, but who knows) a profile, saying to Alexander “What about something like this?”, and off Alexander went.
At Charles’ request, the Mary Rose Trust commissioned Alexander to produce the proposal for building The Mary Rose Museum that is, ostensibly what this book is about. The bulk of the book’s 128 pages is taken up by a description of the proposed museum, outlining its development from the original rough sketch through to a fully costed, structurally feasible design.
At this point, the principle sponsor backed out leaving the project with no funds and it had to be shelved. Alexander says that, by then, he and his team had put in some 5000 man hours of work on the project; I’m sure they must have been gutted to have the plug pulled. A smaller section at the back then goes on to discuss the (much rougher) work the team did on redesigning the museum so that it could be built in incremental fashion without needing all the funds up front in the hope that the Trust’s funding could be spent on something permanent rather than having to spend a large amount of the donated money on temporary measures to maintain the structural integrity of the current ‘tent’ over the ship.
So, it’s a war story from a failed project, why should you part with the thick end of £30 to read about that? And what does all this have to do with programming? Here’s why: Christopher Alexander is the most influential bricks and mortar architect that the world of computer programming has ever known, if only for his work on Pattern Languages and ‘The Quality Without a Name’. As a literary form, the design pattern and the larger pattern language are fabulously useful (and egregiously abused) ways of describing how to solve many of the problems we face as programmers.
However, what is often overlooked about Alexander’s work is that an awful lot of what he advocates about the process of generating a room, building or town foreshadows the processes advocated by the Extreme Programming people. You should not be surprised to learn that Kent Beck, author of the seminal book on XP, was also one of the earliest writers to use design patterns as a way of addressing programming issues.
In The Mary Rose Museum, Alexander describes the ‘agile’ process his team uses on projects, and he also shows the basic contracts between Owner and Architect, and Architect and Subcontractor that he and his team use when building.
As a houseowner who had some fairly substantial house renovation done I’ve been a signatory to a standard RIBA contract for building works, and it’s a very different beast indeed from the Center for Environmental Structure (CES) contracts. I would rather have signed the CES ones. Alexander maintains, and I think I agree with him, that his form of contract deliberately nurtures the process of building something that will live, while the standard contracts are based on the myth that the plan is how it will be and any variation will cost the client. The CES contracts state up front that change happens, and handle that change without having tons of ‘extras’ added to the cost. Here’s an extract from the Craftsman/Subcontractor[2] contract.
ARTICLE 5. CRAFTSMAN’S GOAL. The ultimate purpose of this agreement is to secure the craftsman’s work under conditions which make the craftsman’s work a work of beauty and pride and self-respect, and in which the craftsman leaves behind work he is proud of, and can cherish in the future.
It is specifically understood that the craftsman’s goal is not only to be paid for his work, but that the beauty and satisfaction of the work itself provide part of the craftsman’s reward. To this end, the craftsman shall be treated as an artist who has some power and control over his work as necessary to allow the creation of a beautiful and fitting work within limits accepted by CES.
It seems to me, as someone who believes that we programmers are more craftsmen than engineers, that the CES contracts for building works may well offer a useful model for designing contracts for building software using agile processes. Certainly Alexander has interesting things to say that will repay your careful reading and consideration.
1 One theory my wife has heard is that someone on board said “Ee look, there’s t’ King!” at which point everyone on board rushed over to one side of the ship to take a look, and the subsequent heeling of the ship meant she started shipping water through the lowest gun ports.
2 The contract is careful always to refer to subcontractors as craftsmen “in order to emphasize the craft-like nature of the work which CES expects.”
The Quality Without A Name 1
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 crystallize 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-writers have found a remarkably powerful way of managing complexity by isolating parts of the process of building in individual patterns, but neatly tying them into the greater whole by their use of introductory and closing paragraphs to explain the context in which a pattern is used. 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 (In fact, I was working as a contractor and had a copy of The Timeless Way on my desk when a coworker spotted it and made a remark along the lines of “Ah, going back to the source eh?”, which he then had to explain as I didn’t know what he was talking about.) 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; a very sizable fraction of 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.
