Depends on whether step 2 is a complete rewrite (in a different language) or further hacking to "make it right". My process tends to be: 1. Make it work - Kno

Depends on whether step 2 is a complete rewrite (in a different language) or further hacking to "make it right". My process tends to be: 1. Make it work - Knock up a prototype (lots of assumptions made and noted, limited error checking, etc) 2. Make it right - By starting from scratch and use what was learned in making the prototype 3. Make it fast(er) - Having a prototype, and trying it at scale, should have already given me an idea of what algorithms/structures to use/avoid in Stage #2 but, obviously, a further optimisation stage will almost always be beneficial. Ideally (if time allows) the prototype is written in a completely different language to the desired target. This is the most important point. Most of the production code I write is C and I tend to do my prototypes in Perl. The helps me for several reasons: a) ADTs (lists, hashes/dictionaries, etc) are just easier/quicker in Perl/python/ruby than in C (I do have my own C library that I reuse for ADTs so it's not as if it's a great chore writing them each time, but ADT instantiation is just easier in Perl/python/ruby than C). b) It's also easier to play around with different algorithms if you can switch between ADTs more easily. c) I can use the prototype stage to continue to learn new languages (it used to just be Perl but has extended to include languages like Python and ruby). This list will keep on growing. d) It prevents me (or the business) stopping at Stage #1 and using the prototype code for production. (This could be even worse if the prototype was written in C.) e) A prototype, being quicker to knock up, means faster to getting it in-front of someone else to look at and give feedback. f) It prevents me just copy-and-pasting chunks of the prototype code as production code so I, hopefully, don't carry over any of the assumptions I'd made in creating the prototype. g) "Knock up a prototype" doesn't mean no design/testing/etc. I usually end up with design notes and some automated black box testing that can be reused in the later stages.