Prototyping: Do it right or get it done?

Given that prototype code has a way of becoming ship code and that one usually doesn't have a whole lot of time to play with a prototype, should one take the time to "do it right" or just mock up as many features as you can in your timeframe? 
Hard-coding resource strings:  yes or no?
Globalization: yes or no?
Performance investigation:  yes or no?
What is the priority list of things to do right in a prototype?
Comments (3)

  1. Heh, do it in Director so the prototype stays the prototype. 🙂

  2. Greg says:

    I’m caught in Prototype-Prod code hell now…

    The only thing that saves my sanity is that I have been there before and knew where to skimp and where to take the time to do it right.

    I have to say that "doing it right" will usually save time in the end.

    I find that there are enough "pauses" (decisions needing to be made, meeting re-schedules, people out, etc etc etc) during the design/prototype phase that I can usually get the "right" stuff in.

    If you get to actually throw out your prototype and code fresh for prod, you can always copy the "right" code from the prototype.

    It will always be a trade off, but even during the prototype phase, don’t you feel better when you do it right?

    If I had to prioritize the provided list I would say, Resource/Strings, Performance, Globalization (which will be helped by the Resource/Stings).

  3. Tom Richards says:

    Depends on the customer. Last time I created just a "prototype" in a very short time. I thought I was just providing something that looked good and did what it was supposed to – worked with other customers. It needed performance optization, etc. etc. My mistake – I should have done it right. Instead of just something to show the customer it was used in the final product – not by me, I wanted to re-write it the "right" way. For most of my projects performance is highest priority.

Skip to main content