Why Are You Prototyping?
Beware of the prototyping trap. If you ask two programmers on the same Visual Basic team what a prototype is, you're likely to get two different answers. Often the team is unclear whether or not the prototype is a throwaway. Ensure that the term "prototype" is well defined and that everyone (including the users) is familiar with this definition. You might even choose to define different types of prototypes. The big trap is to leave the "prototype" ill-defined. We have seen this lead to much grief on many Visual Basic projects. Prototyping in general has been given a bad name because of frequent misuse.
Delivering quickly is often the justification for a prototyping approach to development. But without control, the "what" that is delivered usually fails to meet the business needs for robustness and maintainability.
To be successful, prototyping must have specific goals, such as these:
- Goals to demonstrate feasibility
- Analysis goals to discover or confirm requirements
- Design goals to prove the technology or an approach to implementation
- Implementation goals to evolve a working system with user involvement within a predefined technical architecture
Uncontrolled prototyping, without goals and a development strategy to produce an application architecture, is doomed. It is hacking with respectability.
Prototyping can be used at various stages during development. The key principle that will ensure that prototyping is used correctly is to precisely define the objectives of the prototype and then ensure that appropriate disciplines are used to deliver these objectives. Rules such as "Prototypes must be thrown away" are unnecessarily restrictive.