|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |