Constraints Breed Discipline - Blain Smith
Walk into any old stone church and look up. The arches, buttresses, and<br>ribbed vaults that hold the roof against gravity for a thousand years were not<br>chosen for their beauty. They were chosen because stone is heavy and weak in<br>tension, and the people who built those walls had to obey what stone could do.<br>The beauty came later, almost as a side effect. The masons did not have the<br>option to ignore the material. They could not summon a new substance into<br>existence by writing a manifesto about it. The constraint of the stone forced<br>them to think harder, and the thinking is what produced cathedrals.
Software has very few constraints like that, and the ones it does have can be<br>dissolved by writing more software. A bridge engineer cannot decide that<br>load-bearing walls are inconvenient and abolish them by Friday. A pharmacist<br>cannot ship a new compound on Tuesday because the deadline is Wednesday. We<br>can. Every boundary we encounter is implemented in code, and code can be<br>rewritten by whoever has commit access. That power is what makes software so<br>productive, and it is also what makes it so easy to ruin.
The most innovative industries in human history have done their innovation<br>inside constraints, not by escaping from them. Software has spent four<br>decades doing the opposite, and the costs of that choice are now legible in<br>the daily experience of using the systems we have built. The argument here<br>is not against innovation. It is for the discipline that makes innovation<br>possible in the first place.
+++
Christopher Alexander spent his career studying how good buildings get built,<br>and his answer was that the building has to fit its context. He called the<br>process of design the activity of inventing physical things that respond to<br>function. The 1964 book where he laid this out, Notes on the Synthesis of<br>Form, defines design as the work of finding fit between a form and the<br>demands placed on it. An adaptive process will be successful only if it<br>proceeds piecemeal instead of all at once, he wrote, and he pointed to the<br>traditional builders of unselfconscious cultures as the people who got this<br>right. They could not afford to redesign the whole village every generation.<br>They made one change at a time, kept what worked, and discarded what did not.<br>The constraint of slow change is what produced coherent forms.
Alexander is describing a feedback loop. Real constraints force the designer<br>to confront misfits, places where the form fails to meet its context, and<br>to address those misfits one at a time. The designer cannot pretend the<br>misfit does not exist; they have to either change the form or change their<br>understanding of the context. Either way, the work gets sharper.
When the designer has the power to remove the constraint instead of<br>addressing the misfit, the misfit disappears not because the form got<br>better but because the demand was rewritten. The feedback loop that<br>produced cathedrals stops working. This is what software does to itself,<br>and what most modern programming culture treats as a feature rather than a<br>problem.
+++
Henry Petroski spent his career writing about engineering failure, and his<br>central claim is that engineering is a discipline organized around the<br>anticipation of disaster. "Engineering design has as its first and foremost<br>objective the obviation of failure." Bridges, dams, airframes, pressure<br>vessels, the whole catalog of civil engineering exists because someone, once,<br>calculated what would happen if the structure carried more load than it was<br>built for, and then designed it not to. The factor of safety is intended to<br>allow for the bridge built of the weakest imaginable batch of steel to stand<br>up under the heaviest imaginable truck going over the largest imaginable<br>pothole.
Petroski's larger point is that the discipline of civil engineering has been<br>built by studying the failures, not the successes. The colossal disasters that<br>do occur are ultimately failures of design, but the lessons learned from those<br>disasters can do more to advance engineering knowledge than all the successful<br>machines and structures in the world. The Tacoma Narrows bridge twisted<br>itself apart in 1940 because the designers had pushed the slenderness ratio<br>beyond what the existing aerodynamic knowledge could account for. The Kansas<br>City Hyatt Regency walkway collapsed in 1981 because a shop drawing change<br>doubled the load on a single connection. Each disaster left a written record,<br>a code change, a new constraint in the way bridges and buildings get built<br>from then on. The constraint is the lesson.
Civil engineers do not operate under arbitrary constraints. They operate<br>under the accumulated memory of every collapse and fatigue crack the field<br>has recorded. The building code is a graveyard's worth of failure<br>compressed into rules, and anyone who wants to skip the rules is asking to<br>relearn the lessons that killed people. Petroski is careful to say that<br>engineering is a human...