Applying the lessons of XP to bridge building:

http://www.creativyst.com/Doc/Articles/Mgt/AgileBridges/AgileBridges.htm

Oh, two can play at that game:

http://www.softwarereality.com/lifecycle/xp/twin_valley_kingdom.jsp

See also SoftwareAintBridgeBuilding

Those are funny. When's the last time they moved the riverbank while the bridge was under construction though?

''It is common for the riverbank to move while a bridge is under construction.  Usually, this is because the bridge builders deliberately moved the bank.  Sometimes Nature is uncooperative, and moves the bank.  The creation of the Salton Sea is one of the worst-case scenarios.''

----
Software doesn't have to be like bridge building. It doesn't have to be like chip design, or theorem proving or city planning. Software can be its own thing. On this site, we ask, when software is its own thing, what does it want to be?
----
There are fundamental conceptual problems with both of these silly stories. Firstly, TheSourceCodeIsTheDesign, and it is the design we are creating, not the product. In software, we construct the product frequently because we can and because it benefits us. But even in bridge design, a good civil engineer does like an Agile software engineer. He sketches out the design and then refines it. He builds simulations and prototypes in order to see whether the bridge will hold up. He even has the builders incrementally deploy to whatever extent he can, because it gives him early feedback on whether the design is actually sound.

In the Twin Valley Kingdom story, they even did such ridiculous things as have people walk out into the ravine to see if they died when they fell, in order to see whether they actually needed a bridge. Anyone actually using his grey matter, however, will note that this doesn't tell you whether you need a bridge; it only tells you that you shouldn't walk out into the ravine like that. A good bridge designer would do like an Agile engineer: He would think of a some way to test whether he needed a bridge, perhaps by measuring the depth and steepness of the ravine or by measuring how long it took someone to traverse the ravine safely without a bridge. Then he would think of some way to measure what the bridge needs to accomplish. Then he would think of some way to measure whether the bridge design will accomplish this goal, whether through a mock-up or a simulation or whatever. Only then, after his design is proved sound, would he build the bridge.

It actually amazes me that non-Agile software developers frequently get this backwards. In the name of BigDesignUpFront, they avoid writing code. But then when they finally do write code, they have no idea whether it will actually work, or even how they might prove that it actually works. They have this vague concept that they'll test it, and QA will test it, and the customer will test it. Like a civil engineer who refuses to start drawing up blueprints until he has all the bills-of-materials in order, but then generates detailed blueprints and goes right to construction without even thinking about wind tunnels.
----
BuildingSoftwareIsLikeBuildingSoftware

-----
CategoryAgileMethodology