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.
Side note (because I can't resist sticking it to the "other" development language in our company): using Perl, I can generally build the entire thing with 20% of the development time :o) yay Perl :o), double yay CPAN

The references that I mentioned are:
Software Engineering by Roger Pressman (now in its 4th or 5th edition): I think almost everyone who is into software development should take a peek at this book if they haven't already. (Update: thanks to princepawn, its actually Software engineering, a practioners approach. you can find it in the reading list here, also here)
Rapid prototyping by Vonk (I think this has a study on prototyping)

I'll probably update with a few links when I can find them...

One problem is that prototype means different things to different people. I've seen the term applied to:

• GUI mockups to show the users/marketroids
• proof-of-concept to try a particular strategy or collect statistics
• the simplest thing that could possibly work
• a failed first version of a program

• the techniques/tools/languages used to build the prototype are somehow different from the final version
• it's too hard to convert the prototype into a shippable, high quality product.

I think there's a tendency in many organizations to view massive restructuring of code as something that is just not done, rather than as a part of normal development. That's sad, and may have something to do with deficient tools (it's much easier to refactor in Perl or Smalltalk than in C++, and the Refactoring Browser makes it simple and foolproof in Smalltalk).

By minimizing the work done (i.e. not writing anything until it's actually needed), and by testing constantly as new capabilities are added, you always have a working version that will do something. So your system is always its own prototype. This seems more efficient than throwing one away.

Interesting questions, Sherlock!

Has anyone ever convinced someone (be it a manager or a customer, etc.) that the prototype really should be thrown out?

There have been times that this has been a problem for me.

I worked for a company that made tape backup software. One of our big customers (for whom we wrote a backup app that was included in a version of one of their products) was a huge software firm in the Pacific Northwest. They had an immense corporate network (thousands of servers), and their internal IT people had hacked up an enterprise backup system using a language they had developed that is often used for rapid prototyping. For some reason (partly because we didn't have the enterprise features that they wanted), my company actually paid them for this prototype-quality code. Unfortunately, it wasn't exactly robust (this is an understatement). It was an interesting proof of concept, but hardly product quality. We tried to convince our company that it was a bad idea to ship this code, or even work on it. Since they had paid for it, they had the mistaken impression that it was worth something. I left shortly after that, but I think they actually shipped it, and then came to regret it.

Other times, prototypes have been useful while doing hardware/software co-design (I've worked with embedded systems a lot). If you don't have a fully working machine, you don't really need a fully working program to run it. In these cases, it was easy to say "the prototype only worked on the lab machine".

How do you deal with the "kludge" (as DrSax called it) that seems to result from adding features to an application that wasn't initally designed to have those features?

Well, if you do your development right, this doesn't happen. That is, don't over-design up front and then try to patch things on, and be willing to scrap (or at least edit) large amounts of code as you iterate the development. If the design is getting in the way, change it. That's what refactoring is all about. Too often, a "design" becomes sacred and no one wants to change it. Some people even think "design" should be done by different people than the ones who "develop" (don't even get me started on this silliness).

Doesn't your application become difficult to maintain, or are you constantly redesigning as you go?

You're constantly designing. Not re-designing. If you do it right (that is, not trying to gingerly tack on changes), you don't end up with a brittle system.

And, if that's the case, isn't that a lot of work?

Well, it's no more work than building a prototype to throw away and then doing it again a different way.

Finally, have people found that prototypes are more trouble than they're worth?

It depends on what they were intended to do. Generally, you don't have all the answers up front; it's a peculiar belief that systems can be designed up front in their entirety. So always having something that will at least partly work will answer more questions than just thinking about the system during a long "design" phase.

If you're constantly forced to put prototypes into production and that is causing you more headaches than if you hadn't created the prototype at all, is it really worth it?

If you don't have something that's explicitly a prototype, that won't happen. You'll just have a version of your program that is either complete (that is, it does all of what it is supposed to do) or isn't. If it isn't complete, you'll know it, and you'll tell your managers. No problem. That's why it's better (IMO) to evolve a program through iteration than to have an explicit prototype. You always have a version that does something, and you know where you stand with respect to its requirements (because you've already collected all the "stories" about what it is supposed to do).

As a consultant I took a web interface design class. The instructor was extremely knowledgable in this area. The on ething that I took away from that class was drawing the web pages on paper or making them on construction paper. She explained that by doing it this way the client would realize that this was indeed the design phase.

The other benefit of this was an initial usability testing phase. "People off the street" were asked to physically press buttons drawn on the paper to navigate the website after they were given a specific task. This indicated the "ease of use" of the layout.

The interesting thing about the class was that we never got near a computer. It was all paper. Big 3M sheets that stick to the wall, post-its, construction paper. Anything but a real computer and all of the class were web programmers.

I have found through experience that rapid prototyping also helps to manage client expectations when used properly. It kind of gives them that "Little Building" that architects model for their clients while they really design the thing. I am sure everyone is well aware of how much client expectation management plays into the daily stress level.

I my current position, rapid prototyping has put me light years ahead of other newcomers in regards to the product. It has helped me to ask the proper questions. When I started I knew nothing about the industry I am in now. Within a couple of months I was asking questions that others didn't ask until 6 to 9 months down the road.

Good thread to initiate Sherlock