Looking back at the number of times a "prototype" ended up becoming the product, the answer would be yes.

Don t forget that you are not only prototyping the feature, you are also prototyping the design.

Yes to quality. No to optimization. This question should be community wiki.

I would focus on clarity.

If quality and optimisation are requirements for the prototype then yes. If not, then no. Just because you are doing rapid prototyping you don t abandon standard operating procedures like programming to a specification, using source code control, testing, etc. It is, perhaps, relatively unusual for high performance to be a requirement for a rapidly developed prototype, but that s another matter.

Yes. Focus on quality, clarity and simplicity AND comments to explain what its doing and why (don t bother with the how, unless its really complicated, that is what the code is for).

Just about all work we do here starts out as a what if? And if it works we continue with it.

We write comments that describe what should happen, before we write the code, then write the code to match the comments. Writing the comments first forces you to think about how you will structure it all. We ve found that it prevents a lot of FALSE assumptions and actually makes development faster.

It also makes reusing this when you come back to it so much easier - you don t need to read the code and understand it, just read the comments. Don t go for the nonesense of self-documenting code, all that does is self-document the bugs, you ve got nothing to check to see if the code matches the comments/documentation at all.

You can worry about optimization later - see this description of a huge win I got by changing from MFC CMaps to STL when working on a hobby project parsing some Apache log files. This was done after I had the initial concept working and only when it became apparent there was a problem with performance.