When software engineering was young, we patterned the field on architecture. Writing code, we thought, is just like constructing buildings. That's why we have "software architects" who organize "development" projects to "build" products.
We started with "waterfall" construction: first we plan it, then we build it, then we test it, then we throw it over to the wall to the client who has to live with it.
We quickly learned that iterative models work better. Software is more fluid than architecture. Labour, not concrete and glass, is the precious resource. And software is unpredictable in a way that architecture is not. Most of the DNA of any new building is shared with millions of other buildings. Due to the sums of capital at risk, architecture tends toward conservatism. But new software naturally tends to be original – after all, if the software you want already exists, you copy it and use it; you don't rewrite it.
The problem with doing something new and original is that you're fumbling in the dark. Show me a client who thinks they know what they want, and I'll show you a client who, after they see the finished piece, will realize that they wanted something else.
The architect, builder, and writer Christopher Alexander has made a seminal contribution to two fields: architecture and software. His Design Patterns has influenced an entire generation of programmers. This influence is recorded in Richard Gabriel's Patterns of Software.
And now, in Alexander's most recent work, The Nature of Order, Alexander articulates a way of building that, apparently, folk builders have always known, but that modern architects of the 20th century had forgotten.
It turns out that the waterfall software construction of the 1970s and 1980s had a lot in common with what Alexander calls the "big-block" architecture of the 1970s and the 1980s. Both were a mistake. Both arose from the historical high point of mechanistic modernism. Both, with any luck, will be laid to rest in the next few decades.
In software, the path has led to agile development: XP, Scrum, TDD, CI, etc.
In The Nature of Order, Book 3, A Vision of a Living World, Alexander articulates a parallel path for architecture. (pp 501–504)
What is needed as an underpinning for a kind of construction which is truly based on making—hence is responsive to feedback, and allows shaping to occur dynamically during the making process, consistent with the fundamental process. This requires a new form of construction management contract. The construction manager is not paid by profit, but by a fixed amount of money (we typically use 20% of hard cost, or about 17% of the contract). The rest of the money, 83% of the construction contract, is also a fixed sum. It is the manager's responsibility to do the most he possibly can to make a beautiful building, within that money. The system has open books. Clients are able to see the checks, payments, of every penny. Changes can be made (and are expected) inside the total of the 83%, without change-orders. Any time a change is made, within the total of the 83%, and the money needed is obtained by economizing on some other part of the contract. The construction manager's job is to juggle the money within the 83% so as to get the most and best quality of biulding from the given sum. To make this possible, the manager also has the right to reduce certain specifications in the building to compensate for others which have been increased. Thus there is a trust relation. The client knows that he will get just what this money can be stretched to pay for. But he has to be realistic about his expectations, and cannot take the conventional adversarial approach to the construction manager.
My colleagues and I have invented (and used and tested) several types of contract which work like this. The contract type I have used most frequently is the one published on pages 92–98 of The Mary Rose Museum. Many others have also been tried in our company and worked. These contracts are downloadable from natureoforder.com, and patternlanguage.com. All deliver a building for a fixed price and leave the architect/construction-manager as much freedom as possible to do the best job he can do with the available money.
The parallels with Agile Development are obvious.
It is a point of pride with Agile that Agile developers can accurately estimate the schedule needed to implement a feature. This estimating capability allows the Agile process to restructure the power relationship between developer and client.
In traditional software development, the client asks for a set of features to be built by a certain date at a certain price. Grizzled veterans will instantly recognize this as a classic no-win triangle, and gruffly respond: "good, cheap, fast: pick any two".
In Agile development, the client sets the schedule and the budget. The client also prioritizes the list of features. But the developer estimates how many of the features on that list, arranged in priority by the client, can be built within that schedule and that budget. And the client has to live with that estimate. You want more features, you need to allow more time, or pay for more developers.
It is delightfully appropriate that Christopher Alexander, who inspired software with patterns, should be the first to rediscover the Agile dynamic in architecture.