Rapid Application Development: Fast Car No Map and 50 Laps to a “Who House”

[If you have never been involved in a custom software engagement (i.e., on the software builder side, customer buyer side, contract lawyers, etc.), there is no need to read this post.]

Rapid application development and prototyping have their place. One of these places is not the creation of complex, mission critical, ultra-high performance systems (i.e., space shuttles not mash-ups) – where it is essential that in hindsight the system appears well thought out, explainable, maintainable, etc. The simplest post-project assessment being, “Knowing what I know now, I would have built it exactly this way!”

The only method I am aware of that has a reasonable chance of making the above claim involves building a system based on stable, pre-defined, well-conceived blueprints. When operating off tight specifications, what you end up creating is virtually no different that what you were envisioning at the start … including the very first brick laid.

If you start building something without a precise road map, every time you have a design revelation, resource conservation drives one to make compromises. It is in this way that the air conditioning unit ends up on the roof of the car, the stereo mounted to the back of the driver’s seat, and so on. What rapid application development environments can lead to is the fast, iterative (50 laps) construction of a Dr. Suess "Who House" or a Rube Goldberg-like contraption.

My primary issue with rapid prototyping, rapid application development, iterative development, and the like is the creation of valuable artifacts that one is hesitant to later discard at a whim. On this path, it becomes more prudent to perform a least-effort modification of A to become B. This compromise is compelled by the urge to preserve earlier investment … even if the best tact involves utterly discarding A and constructing B from the ground up.

It is therefore my belief that the most valuable prototyping tools, rapid application development environments, etc. are those that leave the designer with a sense of “as close to zero investment.” Radical changes to the design, complete rethinking of a whole component, big shifts in database schema, wholesale rework to the GUI, etc., need to be absorbed in the design phase without an iota of grief.

[One of these days maybe I’ll blog about Computer Aided Software Engineering (CASE) technology. During one era of my life I spent eight years building such technology to automate the blueprint process; hence this subject remains very dear to my heart.]