YouTube – no rewrite

del.icio.us – being rewritten now using a php framework, but got acquired and had massive traffic as a perl app

Digg – probably has had a

Twitter – despite their Ruby scaling woes, they are now in the Alexa top 700, and are still RoR-powered. Their backend tho does have a bunch of fancy mechanisms to deal with massive API requests.

If I had to deal with management, I’d tell them “this is just a prototype” and write it in ruby/python/whatever, but in the back of my mind I’m really thinking the “prototype” can and will evolve into the final app.

thanks for the comment. I was referring to a prototype as a technical a way to test and convince the stakeholders that something is feasible (and that they should finance the project). Depending on the key risks, this can be a technical spike, but can also be a mini version of the target system, stripped of most non-essential functionality, but again showing something end-to-end.

The particular prototype I wrote about involved several middle-ware components and a web site built on top of them. Each of those MW components could be seen as a technical spike, but they did not prove the concept alone – only a mini-system as a whole could prove the concept.

So it was a way of testing real functionality, a specific selection of stories. However, I think that it was beneficial to do it as quick and dirty as possible, as the goal of that “mini-project” was to find a way to solve the risks (technical spike) without burning resources. We estimated that doing it properly would take 3-4 months (which turned out to be correct when we did it on the end) and the quick-and-dirty prototype was done in a month. As it was quick and dirty, building the rest of the system based on that would be very error-prone and cause a lot of problems in production.

Is it a means of testing UI concepts? It should not be usable anyway as it should not have anything but UI.

Is it a means of testing some real functionality? In this case, if it is developed test first there is no reason to throw it away.

An agile prototype is no more than a specific selection of stories to achieve a prototype milestone. It makes total sense to continue and deliver it — we are not wasting effort.

Is it a means of exploring a technical issue? This is where spikes come into play. You test ONLY the technical issue without any connection to real stuff.

In all of these cases there is no danger in the prototype being carried forward:
In the first case – it’s just no possible – there’s no real code there.
In the second case – go ahead, it’s production code as is
In the third case – there is no prototype anyway.

So, I guess I don’t quite see where the problem is. With an agile state of mind the problem just isn’t there.