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!”
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.
[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.]
RELATED POSTS:
Custom Software Scope Changes (Not)
Scalability and Sustainability in Large Information Sharing Systems