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).