Is Rapid prototyping working for anyone?

Replies are listed 'Best First'.
Re: Is Rapid prototyping working for anyone? by dws (Chancellor) on Mar 01, 2002 at 23:55 UTC
Joel Spolsky has an article that touches on one of the big risks of Rapid Prototyping. The risk is that if you focus on getting a polished UI first, particularly if you implement it (even in a prototyping tool), non-technical managers will get a mistaken notion of how far along you really are, and you'll get beaten up for slacking, or have your schedule slashed. I've seen this happen. It isn't pretty. If you're going to do Rapid Prototyping with your customer, do it on paper.	[reply]
Re: Is Rapid prototyping working for anyone? by tstock (Curate) on Mar 02, 2002 at 01:05 UTC
I feel rapid prototyping is only effective for smaller or static applications. When you are forced to start by coding the specifics (focusing on the UI) you lose touch with the generic, making it harder to change code. Management and customers like rapid prototyping because A. sense of progress is easier to gauge and B. lost time by failling to reuse code is not measurable. But then some developers also over-engineer small applications, and rapid prototyping is a good model to fix this. In short, it all depends on the current culture of developers and management in a specific company IMO. Tiago	[reply]
Re (tilly) 1: Is Rapid prototyping working for anyone? by tilly (Archbishop) on Mar 02, 2002 at 03:46 UTC
Like all development techniques, Rapid Prototyping has a time and place. For more on what time and place it properly has I can highly recommend Rapid Development by Steve McConnell.	[reply]
Re: Is Rapid prototyping working for anyone? by Voronich (Hermit) on Mar 04, 2002 at 21:04 UTC
It's a great thing in theory, and no doubt has it's place. But in over a half dozen attempts at various contract assignments in as many years I've had the following problems. Why can't we just use that? What do you mean we have to start all over? It didn't take you that long to do it the first time! Why now?(see above) It didn't look like that in the prototype. (when prototyping & implementation tools are different...) We've been thinking, and that was really great, but now that you're doing it for real we want something different. What's never happened: Great! This is a really handy way of seeing how this is gonna work. No no, I understand, this is just a virtual mock-up. Now I ain't sayin' it's impossible. And I could have just drawn bad lots. But strike me down if I've ever seen it work. Technically it's a wonderful approach (just like my new favorite practice of writing the test tools from the "spec" before even TOUCHING the code body.) But in practice, I'm cynical at best. But then again, I'm a New Yorker. - V	[reply]
Re: Is Rapid prototyping working for anyone? by koolade (Pilgrim) on Mar 05, 2002 at 05:47 UTC
Rapid prototyping has worked wonderfully for me in projects. A lot of clients I've done projects for haven't had a lot of exposure to complex web apps so can't really visualize what they're going to get in the end. A rapid prototype helps them start picturing how it's going to work when they start using it, and not just how it looks on paper. When specs are solely on paper the danger is that it's either so high-level it leaves out crucial details, or that it's so detailed it just reads like computer-gobbledygook to them and they can't pay attention to it. It's way too difficult to describe computer programs strictly on paper, and much much more difficult for a non-programmer to describe or understand those specs. A visual tool cuts away greatly at that learning curve. It's saved a lot of time, headache and (most importantly) money by implementing prototypes with HTML and Javascript and allowing the client to point to what they like, and what they don't like. Of course, sometimes the client uses the opportunity to make bad suggestions, or doesn't understand that the programming still needs to be done, and so on. But that's a lot easier to explain than delivering the project the week it's due and having to tell them that it'll take another few weeks to make a change that they want which they think'll be small but it really isn't. Especially if it's a feature that they expected to be in there in the first place, but you knew that you'd already said in your gobbledygook that it wouldn't be. I'd rather go through the headache of explaining to my client what a rapid prototype is, than have to hurriedly patch beautiful code because last minute changes blew the entire design. Rapide prototying has also been a good CYA tool, since if the client doesn't like what you deliver, you can always compare to the prototype and show that their requests for changes are really beyond the original scope of the project. It helps put a hard stop to the project whereas if specs were too loose, or weren't understood by both parties, it's a lot harder for a client to feel like they got what they asked for and for a developer to feel like they're done. When your client says "I want ecommerce" and you build them a simple shopping cart and they thought you were going to build them the next amazon.com...well, that's not good for anybody.	[reply]