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

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 himself with the loss of nearly 700 men. The story of how the wreck was found, raised and conserved is impressive in itself. I can remember watching BBC specials on the process as it was happening and my amazement at the dedication/insanity of those involved, but that’s not 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 house owner who had some 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 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.