When you're prototyping a new system, what guideline(s) do you use to mark a stop-and-start-over point?
+1
A:
When the one I'm working on doesn't fit the requirements anymore (functional, usability, or otherwise).
Prototypes are meant to be a dispossable item so I never hesitate when throwing one away.
Justin Niessner
2010-04-07 15:02:22
What contortions are you willing to go through to adapt the prototype to the requirements before saying "this doesn't fit"?
Mike Burton
2010-04-07 15:08:34
If you are going to make the prototype into production code, you need to make a conscious decision to do so before you start working on it. The Pragmatic Programmers discuss a "tracer bullet" approach where you take small steps to move closer to the final version of your application. See: http://www.artima.com/intv/tracer.html
Justin Ethier
2010-04-07 15:18:37
A:
When you've de-risked the functionality to a level where you feel ready to write production code.
James Carr
2010-04-07 15:05:10
+1
A:
Typically I write prototypes as part of the architecture/design process, to answer questions that can only be answered by actually working with the code. For example, questions such as:
- Can I do drag & drop in Silverlight?
- What framework would I use to draw interactive canvas objects in WinForms?
Usually you can write a prototype fairly quickly to answer such questions. Obviously the code does not have to be production-quality, it just has to go far enough to answer these questions.
Once you run out of open questions, I would scrap the prototype and finish your "design". Then you are ready to begin creating a production version.
Justin Ethier
2010-04-07 15:06:27
I think mostly what I've learned here is that whatever I'm doing, it's not really "prototyping" as people define it. However this strikes me as the best answer to the question asked.
Mike Burton
2010-04-08 18:12:03