|Problems? Is your data what you think it is?|
Re: Does Anyone Use Rapid Prototyping?by tinman (Curate)
|on Jun 25, 2001 at 21:36 UTC||Need Help??|
I use it all the time, usually to meet deadlines :o)
A good method to prototype would have the benefits you mention, namely, gives a lot of information about the problem domain, helps you figure out exactly what the usability and requirements are... however, reducing development time doesn't necessarily happen...
In my scenario, Perl (and sometimes Python and sometimes even PHP) are used to build a prototype. At the start of a project, we (the development manager and I) sit down and try to identify what features we will present in the prototype, and what we will not...then, I build it.
As far as person hours go, what I seem to do is produce a working model of the system. I work in an offshore company, where there is a huge difference in timezones between the client site and where the actual developers reside. We actually find that building a working prototype is a far more effective means of communicating with developers than simply producing a requirements document. Obviously, there are some other advantages as well. Firstly, building a prototype allows a rough estimation of timelines to be made. I can honestly say that I have limited experience in project management, and actually building something (with the core features included) gives me a general idea how much time to ask for (of course, asking and getting the time I want are two entirely different things... :o)
So far, so good.. now here's the bad part. In our case, the prototyping environment is seldom the same as the development environment. This means that the development times for the prototype do not always scale properly with the development times for the actual product. Secondly, I have seen a tendency (I try to avoid this as much as it can, but it creeps in somehow :o( to underdocument and code somewhat sloppily. The general reason is that I usually *know* its a throwaway application. So, neither my development manager nor I are really worried about maintaining all the coding or documentation standards that would accompany the real product. In the rare cases where the prototype actually evolves to become the product we deliver, this means a few sleepless nights rewriting some sections, documenting and generally sprucing up things.. So, writing to throw away can mean that standards drop (hey, you know its destined for the trash can, so you don't make it as tight as it can go). A reference that I will mention a bit further on also makes this case, that a prototype is usually written using a slower language, and is only optimized for feature presentation. Sometimes, the amount of redesign and re-engineering involved in making that production code can be significant.
Another negative thing I've noticed is that its very very difficult to convince a customer that you need at least double the time, when you show them a prototype that has all the features that they need. Regrettably, this has been the reason some of my "prototypes" actually made it to production: a demand for a faster delivery time by the client. Therefore, through hard-won experience, we never spend more than 20% of our forecast development time on the prototype.
The references that I mentioned are:
I'll probably update with a few links when I can find them...