Sometimes we write code that we know will be thrown away - especially in the discovery phase of a feature or product. The problem is, often circumstances cause this sort of code to be shipped. I imagine a fair amount of cursing under one's breath the previous developer who worked on code could be the result of this sort of situation. Writing throwaway code is not necessarily a bad thing though. There may be many layers beneath the final product on a painter's canvas, just as a finished novel or script has had entire sections thrown out or rewritten. What we want to avoid is unmaintainable code (which was knowingly written as such) getting forced out the door once a decision maker sees that "it's working."
In his book, Game Programming Patterns, Robert Nystrom makes a wonderful suggestion on defending against this scenario in the case of building prototypes.
One trick to ensuring your prototype code isn't obliged to become real code is to write it in a language different from the one your game uses. That way, you have to rewrite it before it can end up in your actual game.
Regardless of the method used, he notes that we should "make sure the people using throwaway code understand that even though it kind of looks like it works, it cannot be maintained and must be rewritten."