>> Rapid prototyping /can/ be very useful for figuring out exactly what you
>> do and don't want from an application. And iterative prototyping (which
>> isn't the same thing) can be useful for trying out design alternatives.
>
>    Well, that's the theory, and that's why so many project managers get
> infatuated with the idea. Also, it helps catching design mistakes early
> in the project, saving a lot of work.

Yeah, that's the theory.

> At least in theory. The practice, however, can be quite ugly.  What usually
> happens in reality is something like this:

 From what I've seen, the theory goes wrong when one of the following 
happens:

- You throw together a quick "prototype", which somehow becomes "the 
final application", and you end up having to actually "support" this thing.

- The program gets so many feature requests that the entire scope of the 
program is fundamentally altered. Sometimes a program designed for X 
ends up having to do Y instead (where X and Y aren't really related), 
but a much more common paradigm is where a program designed to do X ends 
up being required to do X, Y, Z, W, K, R, J, L, S and V. And maybe you 
could add F as well? By the weekend?

- Management think that "rapid prototyping" means "we can get away with 
one tenth of the usual development time and one hundreds of the manpower 
and still produce a working product". Uh, no, no you cannot.

> The time has come to throw everything to the
> trash and start from scratch. However, there are these things called
> deadlines. Managers want results. They don't want programmers spending
> the next two months starting the project from scratch. This is especially
> so because the managers want *rapid* prototyping. They don't want to wait
> two months for a new prototype.

Ah yes, the source of a million bugs...

Post a reply to this message