Just enough and no more

Christopher Alexander ran his projects with a fiscal policy paralleling that of agile developments. He developed a method to drive the process towards a more natural sequence of growth from local decision-making. Traditionally, building projects went something like this:

  1. They are budgeted
  2. A plot is found
  3. An architect is appointed and draws up preliminary designs
  4. Planning permissions and other approvals are set in progress
  5. A building contractor is brought in
  6. The physical work of the construction takes place

With the stricter budget but flexible spending structure introduced by Alexander, customers would often get much more of what they needed and far less of what was unimportant to them. This echoes the principle of preferring working software over documentation and customer collaboration over contracts.

When you have a multi-stage process, you find budgets become a playground for corruption and profiteering.

At each step, the goal of the individual developer is not to build a delightful building for as little as possible but to make as much money from the building process as they can without breaching their contract. Essentially, cost-cutting practices increase costs.

  • Engineers are rewarded for spending more time than required on a project when it pays for extra hours without pre-approval
  • Builders are pushed to select the cheapest materials and least expensive suppliers that fulfil their constraints in order to compete
  • Once a contract is in place, verbal promises do not bind
  • Work continues as long as no breaches are detected, compounding the effect of the sunk-cost fallacy. Often, it seems easier and cheaper to accept the exploitation of wording than to find an alternative contractor
  • The whole tender process is naturally biased towards those who will do the work for less rather than those who aim to produce the best possible outcome

Agile development could1 break this cost inflation by doing the same thing Christopher Alexander did. The budget could be set, and the delivery should be decided upon. If something costs more than expected, it is made smaller, or something else takes the hit and is reduced in quality/quantity or withdrawn. No one is allowed to spend the excess because usually there is none. And even if there is, it is returned to the entity commissioning the project.

We reinforce this further by following another tenet of Christopher Alexander’s processes: delivering regularly and getting feedback from the client. This way, they also get to see the work in progress and decide what they really want now that they can see the product closer to the final form. The clients don’t pay for what they didn’t ask for. Instead, we offer them the chance to see what they need to ask for.

In most of the projects run in the Alexandrian way, builders and architects worked locally, iteratively, and directly on the site. They were present in the client’s context. The time cost for uncovering a revelation and getting a response was tiny and sometimes non-existent as the client may have been part of the labour force. This waste reduction in the form of zero or minimal response time requires a solid link to the customer with regular feedback sessions or a knowledgeable client representative.

Working on site also meant that the architect and the builders were practising continuous integration and delivery with bricks. They included other aspects, such as continuous improvement of their processes, as they built the necessary tools on demand. They designed new ways to construct with prototypes and proofs of concept. In one project[TPoH85] they even had brick machines on site to create just what was needed and invented novel roofing techniques using thin wood strips and concrete-reinforced canvas to match the available local resources.

All this was just enough and no more. Christopher Alexander did not use these projects to fund some irrelevant side research. Instead, he charged a fair and reasonable fee. He did not overcharge based on his reputation or undercut to get the contract. This would later prove to work against him, as the wider world did not play by his rules.

1

It’s possible, but as we know from experience, organisations claiming to follow agile development practices often use the names, but the actions remain the same.