I’ve heard this story before

“It started as a prototype, but got pushed into production”


All of the very worst systems I’ve worked with have an origination story that can be summed up by the 10 words above.  If you hear these words, either run or go into legacy code mode.


Prototypes are dangerous.  Dangerous in that they can easily go on way past the point of diminishing returns, and dangerous in the sense that there’s too much temptation to put it into production.  When you prototype, I think you need to decide right off the bat what the limited goal of the prototype is and set a timebox for the effort.  There has to be an acknowledgement that we’re temporarily coding without the safety regulator of good practices and plan on throwing away the prototype code later.


I said much more earlier at Of Spikes and Prototypes

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Ranting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://secretGeek.net secretGeek

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

  • Gregor Suttie

    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.

  • http://www.e-Crescendo.com jdn

    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.

  • SteveJ

    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

  • http://www.rauchy.net rauchy

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

  • John

    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.

  • KG2V

    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++?

  • Dave

    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.

  • http://devlicio.us/blogs/derik_whittaker/default.aspx Derik Whittaker

    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.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @TimB: Then don’t write a prototype at all. Go immediately into writing production quality code one feature at a time.

    @jdn: You’re living on borrowed time dude. You’re like the characters in a bad horror movie that have cheated Death. Wait until you get someone else’s prototype ;-)

  • http://www.e-Crescendo.com jdn

    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.

  • http://www.mgroves.com mgroves

    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.

  • http://bigtunatim.wordpress.com Tim B

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