[crazy1van]

I disagree a bit with these points. Sure, ideally you'd avoid all of these issues and having these issues several years into a product is certainly bad. But when a new product is just getting off the ground, there is a hefty cost to Doing It Right. I think many successful products would never have launched if a scary number of corners weren't cut to get version 1.0 out the door.

[loup-vaillant]

Depends what kind of product. If you're a start-up launching for Christmas, sure. But if it's a contract to deliver some long term custom product at a multi-year deadline (I have worked on such things), then you should definitely not push that prototype.

(Actually, the inverse error is often made: trying to get it right the first time around, which is impossible. A prototype is even worse, but least you can test your major ideas, so you can see which are good, and which are hopeless.)

[ak39]

I think the "prototype" analogue borrowed from engineering to software is a bit problematic. I don't believe there is such a thing as a "working prototype" in software. It either works or it doesn't. If it works and that's what business needs in the production environment, then ship it already. Nothing wrong with that.

The problems start arising when the issues of scalability and maintenance were not considered part of the prototype development. And this problem does not only affect "carcinogenic prototypes" [sic] ... such problems manifest, and do so regularly, with software projects that had multi-year deadlines and good intentions all-round vis-à-vis scalability and easy maintenance.

[pnathan]

These aren't technical issues. These are issues of process and management.

I strongly doubt they have much unique to software development systems, to be honest.