24 Nov 2008 (updated 24 Nov 2008 at 23:08 UTC)
»
The Timeless Way of Building: Diagnosis and Repair
Architect Christopher Alexander's A
Pattern Language is well known among programmers as the
inspiration for the Design Patterns school of thought, but
for some reason his other books are less widely read. My
mother and father are both architects—"real" ones, not
"software architects." :) My own amateur interest in the
subject led me to read several of Alexander's books over the
past couple of years.
The
Timeless Way of Building is the first volume of
an open-ended series. (A Pattern Language is
the second.) It is in this book that Alexander first lays
out the
idea of a pattern language. More importantly, he explains
an entire theory and practice of design and construction, of
which the pattern language is only one piece.
Another piece of the Timeless Way is the practice of
diagnosis and repair. Rather than a
detailed plan of future projects, Alexander prefers to
maintain a diagnosis of current problems. Each new
project must be targeted at fixing these existing problem in
the system: "At every moment we use the defects of the
present state as the starting point for the definition of
the new state" (p. 485). Alexander's goal is to create
a type of spontaneous
growth and order that is possible when change is incremental
and decision-making authority is decentralized.
Alexander was hired to produce a new type of master plan
for the University of Oregon campus. The result was
published as the third volume in the "Timeless Way" series:
The
Oregon Experiment. In it, he writes again
about diagnosis and repair:
It is still not clear where global order will
come from, without a master plan.… How is the problem
solved in an organism? Essentially, the problem is solved by
a process of diagnosis and local repair.… The master
plan tells us what is right for the future. The diagnosis
tells us what is wrong for the present. (p.
146–148)
In software, the same problems and conclusions have led
to "agile" processes, which emphasize incremental change
and flexible planning. But I haven't seen any software
companies adopt a consistent practice of
"diagnosis"—keeping track of what's wrong or
unsatisfactory with the current system. This extends beyond
defect tracking; it should include a constantly updated list of
code that, although it works, is hard to understand,
difficult to
change, or otherwise likely to cause problems. (This
should be easy to generate—every programmer knows
certain parts of their code base that they dread working on
for one reason or another.) This
knowledge can then guide new development to include "repair"
and address such problems before they become defects. I've
applied this on a small scale to my own work, and now I wish I
had used it at Amazon, where my team spent much more time
maintaining and improving old code than writing new code.
