Sometimes I hear developers say that they are scared to build prototypes because their manager will make them ship it as a product. There is a big difference between a prototype and a product. A home builder wouldn’t mock up a house out of cardboard and then try to sell it so people could move in even though it might hold up on a dry summer’s night.
Prototypes help us understand what a product will be like or we can use them as a proof of concept to validate some of our assumptions about what we are building. But a prototype is not a product because it does not have the robustness or supportability of a product yet.
It is fine to take shortcuts when building a prototype. The purpose of a prototype is to elicit feedback from others or verify a design approach will work. When doing this we generally only concern ourselves with the “happy path” through our code. This is ok as long as we later go back and handle the error cases we missed.
Prototypes can also be sloppy. When we are trying out ideas that we aren’t sure are going to fly we may not have the most intention revealing names for our methods. The process of turning a prototype into a product should focus on making the code more robust and more supportable.
There is a very different mindset we use when building a prototype verses building a product. Prototypes can be quick and dirty; products must be robust. When we don’t pay attention to the productizing phase of development we end up driving the cost of ownership up significantly for the software we build.