I just made this post to the SW-IMPROVE discussion list –
Tom Walton Wrote:
I have had people tell me that it impossible to produce any design documentation until after the code is developed for just that reason. They were developing by trial and error. If one thing didn’t work quite as expected, then they tried again.
Tom has just described the engineering strategy used by the Wright Brothers to create the first powered, sustained, controlled, heavier than air flight. Yes, they had wind tunnels, but the key is that the wright brothers figured out what would work through empirical experiment instead of speculation and dogma.
It is also the engineering strategy used by the Gossamer Condor – the first human-powered heavier-than-air flight.
The biggest issue with the gossamer condor was weight, so the strategy was basically this: Weaken every component until they break. Then strengthen that component just enough that something else breaks first. When the smithsonian called and asked for the condor and the blueprints, someone had to make up the blueprints. At least one component was simply bent into place.
So, here’s my thought: If you are doing ground breaking work – creating a new web 2.0 site that is a wicked problem under tight constraints, then feedback is critically important, and “fail fast” might be the right approach. If you are cranking out yet another Create, Read, Update, Delete web form for the department of defense, then you just might be able to specify the system up front. The problem is that in that world, the developer is a commodity who doesn’t add a lot of value.
So, my friends, I’m not really excited about chasing complete, consistent, and correct requirements with a complete spec.(*) In that case, I can’t add much value. No, I want the vague and ambiguous problems – the problems that management has a hard time articulating. Then I use craft to ask a lot of questions and collaborativly *invent* a solution.
(*) – Just as I’m not interested in chasing Big Foot or the Loch Ness Monster.