Jeremy D. Miller -- The Shade Tree Developer

I'm starting to believe that regardless of the initial constraints you place on its goals, a prototype becomes the de facto baseline and it WILL be abused in the interests of expediency.  

Maybe I'm just jaded though ;)

This is so true, but I did one of these "prototypes" that's been in production for a good 2-3 years now...imagine my surprise.

I've seen a number of prototypes that have ended up in production, and haven't required hardly any, if any, maintenance or modification.

Though mostly only when there is some limited area that it sits in.

This happens ALL the time.  One rule i have lived by if I MUST do a prototype is to make sure the UI is UGLY.  I have found that if the user thinks is is ugly they will tend to not push for it to go into production.

In the business world, we're developing software to solve a business problem -- whether it's an internal need or external customer need.  Once you've written code that sufficiently solves a business need, it becomes valuable to the company to push it into production.  If the software results in making or saving money, it doesn't really matter if the code is pretty or maintainable.  And once it's in production and under maintenance, the software begins to codify business logic in a manner that makes it nearly impossible to ever catch up to the "prototype" with a rewrite.  It doesn't make business sense to throw away code that makes or saves money now.

The problem is compounded by non-technical managers who fundamentally lack the understanding that two pieces of software that are functionally equivalent from a user standpoint can vary greatly in implementation.  When they see two functionally equivalent pieces of software, they naturally assume that adding Feature X to one should take the same amount of work as the other.  

I think we have to understand this as developers and adapt accordingly.  If I'm developing a "prototype" that has any chance of being useful, I spend the extra little bit of time up front to lay out the code in a fashion that'll be usable in the future rather than spewing forth throw-away code like we developers tend to like to do.  It doesn't take that much more time to lay down the framework for maintainable code and the result satisfies the needs of providing a quick solution while leaving room for future growth.  

That said - one or two of the best projects I ever worked on were "fully functional prototypes" - in NAME

The company I was working for  circa 1992 had a policy - ALL "production" Windows applications HAD to be written in C++ - However, "prototypes" were writeen in Visual Basic.  What ended up happening was they ended up with a "new category" per management "The Production Prototype" - Prototypes that were intended from the word "go" to go into production while they were translated into C++ by the "Main IT group"

Guess how many of those "production prototypes" were EVER translated into C++?

Jeremy raised a good topic, but I do not think his suggestion is feasible unless you are the manager. I like Dave's idea of spending a little more time to make the prototype expandable is more realistic. Derik's idea is good but only work in an enterprise not as consulting.

So true.

This brings me back to a project I did a few years ago where on the first day on the project I shouted out that the intentions to use the prototype as a base for production code is simply horrible. My idiot-soon-to-be-replaced-by-me boss said "What? have you never heard of a rolling prototype?", well, that turned out into a nightmare.

Derik - I used your ugly UI technique, but the only thing which resulted from it was a console application which is still in production :-)

You've seen the napkin look and feel before right?  It's the only useful thing I think came out of the entire skinnable movement.

http://tinyurl.com/2vne7y

To a certain extent, I think the possible success of a prototype depends on whether the end result is viewable through a UI.

For a vast number of the ETL typ code projects I've worked with or witnessed, the prototype is the production code.  Once it works, it works.  You get things like a vendor changing a file format every once in a while, which requires you to change code, but other than that, once it is done, it's done.

And, blasphemous as it might sound, you don't really need a lot of unit testing or integration testing for these sorts of projects at all.  It either works or it doesn't, and once it works, you are done.

I think there is a lot of code that falls into this area.

Aggh been bitten by this one as well - 40 days prototype turns into 2 year project that gets rolled out having been started off with some hard coded shortcuts - you gotta love it.

This is like some kind of evil twin to Gall's Law:

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."