Extreme Programming Aint Prototyping

A common pattern on ExtremeProgramming and ComputerProgramming forums: The OldTroll will scoff at temporary solutions, and then blame XP for "quick fixes". A newbie may then reply something like:

If you were building a bridge then the engineer would expect to design in outline, get the design approved, design in detail, get the design approved, and then build the bridge to those specifications. He wouldn't tolerate much "could you just run a railway line over the top?".

The book NotesOnTheSynthesisOfForm applies here.

The source code is the blueprint. The compiler is all the construction workers and raw materials.

First, you start with a 2-foot wide brook, and you throw a plank over it. Then you widen the brook to a stream, throw a log over it, and nail a plank to this. Then you widen the stream to a creek, throw two logs over it, and nail a wider plank across this. And each time you use the bridge for a decade or two, to observe its wear patterns, and rate how much load it can bear.

Each time you incrementally increase the number of features in the goal, and then you apply an engineering solution that's closest to the last solution. And each time where the solution rubs or does not fit, you make minor, incremental adjustments. Along the way, you learn about the tolerances of materials, ways to fit them together, and their potential lifespans.

Eventually you have steel cable suspension bridges. Your confidence about their performance is very high, because you have complete detailed & readable blueprints for them, and you have the cumulated experience of all those former prototypical bridges.

-- PhlIp

See ProgrammingAintManufacturing

This page is an AnalogyBetweenProgrammingAndManufacturing.