Ever wondered what the Golden Gate Bridge would look like if software engineers had been tasked to build it?
Chances are, after the first brainstorming, one engineer starts building a prototype — maybe over the weekend. One lane, using limestone, his favorite building material (after all ‘limestone has been known to be the best building material for centuries’), nice little arches, 
maybe not exactly at the right position but good enough to get a first impression of what a bridge in this location could look like. Quickly, a few other excited engineers help out. They change the material mid-way to granite (after all “granite is known to be the best building material for bridges for centuries”) and add a bicycle lane. A massive tower is added as look-out for tourists sure to visit the bridge every year — a key requirement, everybody agrees.
At the next brainstorming, the prototype is unveiled and by unanimous vote the brainstorming meetings are henceforth turned into status meetings. Program Management is delighted to see early results and upper management praises the success of agile development and rapid prototyping: “It would have taken our competitors months even just to select the site!” More resources are poured into the project and the one-car-one-bicycle-lane project is quickly advanced. To make up for the unfortunate choice of location, a sharp turn is inserted half-way–“hey, it worked for the Bay Bridge“. Adding another 5 lanes for traffic is postponed for a future release together with widening the arches for ship traffic. Several segments need rebuilding in different material even before the middle of the strait is reached as granite turns out to be great material for building castles but not so much for bridges.
With being only 6 times over budget and 2.5 years behind schedule the project is considered a success and declared ready for beta testing! The numerous feature requests of beta testers and early casualties are considered normal fall-out of the effort, after all you can’t make an omelet without breaking eggs.
For years to come the company will restructure the bridge over an over again, change materials, change the geometry, maybe even move the bridge, build another bridge next to it, rebuild the bridge, and so on.
At some point I hope Patrick Lencioni will write a book about this, but I think you get my point.
Protypes and Software
The software industry has a long tradition of building prototype software, even rapidly prototyping. There’s a good reason to build prototypes: to find answers to hard questions. Any situation for which modeling the behavior of software is complex or significantly more effort than building software is a good candidate to prototype software. Not to mention the realm of user interfaces where you just have to see what it looks like. However, we have always been uncannily fascinated with prototypes even for scientific programming and enterprise software development. Most prototypes prove in essence, well, that somebody managed to write a prototype, and that’s it.
The challenge is usually not building a piece of software, the challenge is building a piece of software that meets the requirements, does what it is supposed to do, is flexible enough to accommodate future business scenarios, is verifiable, so we can actually reason about the correctness, robust enough so others can make changes confidently without having to study the code for days, etc.
Prototypes escaped into production wreak a huge toll on your development. For years to come you will curse the day you allowed one of these to go into production for enterprise software.
Here are my rules for when and how to prototype:
- You need a prototype when you got a problem that cannot be modeled/described analytically in advance. For example, if you need to assess the degree of parallelism in a distributed execution of some component.
- Make it a point that the prototype will not be productized but discarded afterwards; set expectations accordingly.
- If you can, write the prototype outside of the existing product and use a language that is suitable for prototyping — don’t write prototypes in C/C++ but in Prolog, Python, Erlang etc. it will help you get results quick and make it easier to resist turning sloppy prototypes into a product.
If you don’t have hard questions that need answering, don’t prototype. Rather, spend your energy on thinking it through and building decent software from the get go. I know it’s harder but you’ll see it’s worth it!
theory in practice 
identify the reasons why analyst prefers prototyping
Simply put, because analysts do not have to maintain the product. They couldn’t care less if your engineering is sustainable — all they count is features.
Your key point, for me, is that a prototype should never be productionised. Far too often they don’t get discarded or pushed aside as people have an aversion to starting again.
Another perspective…
I once started a company with a prototype in hand. We thought that we could productize it in a couple of months and go to market.
My CTO argued that we should not turn the prototype into a product. We had several very advanced ideas that would be difficult to implement on the prototype… so the prototype would quickly have to be thrown away. The CTO argued that he could build a strong and extensible foundation, and provide the business functionality in 6-9 months.
Two years later we sold the IP to another company and folded up our tents having failed to deliver a product to the market.
Time to market counts… I knew it and yet I let the engineer override the exec in me. I learned that the decision to make a prototype a product is not always about engineering.