Tragedy
There’s always a moment, in a perfect tragedy, where you dare to hope that maybe the heroes are going to break the surface tension of the plot and escape. That perfect moment in Romeo and Juliet where, no matter how often you’ve seen it, you hope that this time, Juliet’s message will reach Romeo. Or, when watching Cruel Intentions, you find yourself hoping that the writers have managed to wangle a happy ending.
It never happens of course, and we’d be disappointed if it did. We are taken to the critical point, when everything seems possible, when the characters are pushed to their utmost… and fail. Give me the life and death struggles of two teenagers for whom love is everything and life isn’t worth living without it over the pat solutions of the Dream, or give me “Fortinbras, knee deep in Danes” over the cross dressing, weddings and cruel taunts of Twelfth Night. (Not that I don’t enjoy the comedies).
What brought this one?
Why am I musing on tragedy instead of code?
The explanation is simple: I just watched the last ever episode of The Wire.
If you follow the show yourself, nothing more is needed. If you don’t, why not? Okay, so if you’re in the UK you’re reduced to paying the Murdoch tax, buying the DVDs or watching through Bittorrent (and only Bittorrent is up to date), but you should. All five seasons of The Wire add up to being the best thing I’ve ever seen on television. It’s impossible to describe how good it is without misrepresenting the whole. It’s the kind of campaigning documentary fiction which would make Dickens or Mrs Gaskell proud. It’s a sprawling epic with a huge cast of fascinating and flawed characters. It’s the story of how a cop destroys his career, a junky kicks his habit, a school system fails its pupils, politicians fail their constituents, a newspaper fails its readers and how a policy of prohibition fails a country.
Prohibition and its consequences are shot through the fabric of The Wire. It’s easy to see how drugs destroy addicts. Easy (for liberal old me at least) to see how the money spent in the War on Drugs could be spent more effectively. What’s not so easy, and what The Wire does so well, is to show how “the game” destroys generation after generation of the best and brightest of the urban poor too. Why bother working to get to college, or getting a regular job when selling drugs is so easy and so profitable? If you’re going to jail for selling the stuff in the first place, why scruple to put a bullet in the head of a business rival, witness, or some mope who calls you a coward? How many “mute, inglorious Miltons” end up dead and decaying in a walled up vacant, or stuck behind the barbed wire of the state pen serving out their natural lives with no hope of parole?
And what does putting them away achieve? For every small victory, we’re shown a corresponding fall. New characters slot into the rôles they have vacated and the cycle begins again. It’s a perfect tragedy – the game is still rigged and only the players change. The gods are unmoved by the struggles of poor mortals, the lawyers get richer, incompetence is rewarded and money is siphoned away from the streets into the pockets of rich white men who already have plenty.
Welcome to Baltimore. Have a nice day.
Had we but world enough, and time: Serenity
Joss Whedon’s Firefly was a sf series that was never given time; episodes were jumbled by the network and the show got cancelled just when it was starting to build a serious fanbase. And that’s all she wrote.
Except, as fans of Buffy and Angel know, Joss Whedon doesn’t tell the same stories as everyone else. He managed to hold his cast together and found the funding to make Serenity. It isn’t quite the film of series they didn’t have time to make, but it comes close.
Capsule review: I liked it. I liked it a lot. You should see it.
For a slightly longer, and possibly spoilery review, kindly step behind this curtain…
I really liked Firefly. I pulled the episodes down via bittorrent as they became available and watched them in all their lo-fi glory, putting up with jaggies, out of sync audio and the rest. I bought the DVDs, downloaded the soundtrack and, a couple of weeks ago, went to one of UK’s “Can’t Stop The Signal” previews of the finished movie and laughed in all the right places as, instead of the usual previews, Joss introduced the film.
The film is great. Like most modern sf films, it’s something of a ride. There’s even the cliche of the big fight over the bottomless pit in there somewhere. But there’s snappy dialogue and food for thought too, and some beautifully violent fights (everyone else take note, casting a dancer as your lethal weapon is a good move).
However…
But at my back I always hear
Time’s wingèd chariot hurrying near
—Andrew Marvell, To His Coy Mistress
You can almost hear Time’s chariot as you watch Serenity. The shows were never slow, but the film rattles along at astonishing speed: there’s no time for sitting round the galley table; no time to give sense of lives being lived; no time for Shepherd Book; no time for anything that isn’t going to be relevant within the space of this film. Most films do this, but it’s more noticeable when you already know the characters from a TV series.
The decision makers at Fox took that time away. The bastards. I really want to see Serenity get spun off into another TV series, but the grapevine has it that that’s not going to happen—apparently Fox won’t relinquish the rights. The bastards.
“If you can’t do something smart, do something right”
Thomas More: The last temptation is the final treason,
To do the right thing for the wrong reason
—TS Eliot Murder in the Cathedral
If the film has a message, and I think it does, it’s the same one that Whedon sent in Buffy and Angel. Morality is about personal choice. When it comes down to it, integrity is all that we have and that integrity only exists if you have the freedom to do the wrong thing. For Joss, the greatest sin is taking someone’s freedom to sin from them, because by doing that you take away their chance of redemption.
Which brings us perilously close to politics, but I’ll save that for another entry.
'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.
