While prototyping, to what extent do you throw best practices out of the door in favor of code-and-fix hacking? Granted that the code is not intended to be kept in full production.
Add: I am working on a rather large semi-working prototype made in Python, to figure out the UI for an embedded application. I know that the code is not intended to be used in production, but still it annoys me that the quality of the code base declines steadily with the number of changes done.
For a prototype, only the outside is really important. If you are brave enough to throw away the code afterwards, you can use any dirty trick in the book as long as it looks great.
Remember, a prototype is just a tool to get a customer response. (Yeah I like it, or, why have you put that option there?).
I throw out 'clean' methods and commenting (i.e. utility classes that 'make things happen'), but not "business objects" if you will.
So for example, if I have the choice between defining a "Car" class to define string value properties of "WheelCount", "DoorCount", or just making a quick Hashtable, I'll generally go ahead and spend a little extra time creating the Car class.
The reason for this is because when I go back to re-code it later, it makes more sense to look at real class names (and sometimes these little classes are transferable to the 'real' version).
The biggest danger in prototyping in general is thinking "I'll fix it later" and then not doing it... so if at ANY point you think in your mind "I have a pretty good idea about how I need to do this class", go ahead and spend a few extra minutes on that class and do it right so you can re-use it.
It depends upon what your prototype is trying to prove. Are you prototyping the UI for usability and to demonstrate to clients or are you prototyping an architecture?
If I'm prototyping a UI then I'll throw away everything once the concept has been through iterations and proven.
If I'm prototyping an architecture then the final code will conform to best practices and be usable.
That said, it's amazing the amount of hack job prototypes that end up in full production due to time or budget constraints. If your intention is for the code to not end up in production (ie a UI prototype) then it can be useful to mock up screenshots rather than code them.
Unfortunately, I have had too many prototypes turn into the baseline product due to time constraints. So ideally, you'll follow best practices. Realistically, you do what it takes to get the job done in order to meet whatever deadline you are shooting for. Don't expect the opportunity to completely rewrite. What you come up with will frequently be the baseline, especially if it took more than a few days to develop. The best advice is to learn to use best practices at hacker level speeds.
I almost always treat prototypes (referred to as "spikes" round here) as throwaway code. The point of a prototype is to gain understanding of a problem, not to solve it. That understanding is far more important than any code artefacts, and implementing the solution correctly should be trivial (if it is not, I would argue the scope of the spike is too large).
You could refactor the prototype into a fit state, but in my experience it is faster to rewrite from scratch, given that it has to integrate with a wider system.