I believe in the value of prototypes.
So do manufacturers, designers, and silicon valley. New hardware concepts at large coprorations like Google, Apple, and Microsoft are accompanied by many prototypes (for example Google Glass).
User interface prototypes are key to discovering usability and are commonly used by designers. Often this starts with pen and paper before a single mouse is clicked or keystroke registered.
One similarity shared by all prototypes I want to mention before continuing is this: prototypes are never meant for use by the end user. In the case of Agile software development, we may have a select group of users work with prototypes with the knowledge that they will never see production usage in their current state. Additionally, if a piece of software serves some purpose in a production environment, it must be developed as such.
Opinions will vary on this subject, but here are the most important traits of a software prototype in my opinion.
- A software prototype is developed in isolation. No (or absolute minimum) interaction with existing code.
- A software prototype follows coding standards. We write clean code regardless of its final use. Perfect practice makes perfect results.
- A software prototype is written by people who are constantly learning and training to hone their craft. More on this later.
- A software prototype is written by people who will be responsible for writing the finished product.
- A software prototype is discarded. I repeat. Throw it away after demoing it.
When the above specifications are followed, we gain some specific benefits.
- We are provided the opportunity to experiment with a few of the myriad different solutions to a given problem.
- We have the opportunity to learn from mistakes before creating a production-worthy solution.
- We have the opportunity to use the best design possible based on first-hand knowledge when creating the final product.
- Product/business people see their concepts in action earlier in the software development lifecycle.
- Other groups/departments aren’t paying people to learn to develop software they aren’t ultimately going to create.
- The company enjoys faster overall development times as technical debt remains low.
My continued belief is that many companies have a large disconnect between technical and business people on the purpose and value of software prototypes. Prototypes are as much for developers and engineers as they are for business and product people. Technical teams should own prototype implementations.
I agree that prototypes are invaluable. However, I think you don’t say out loud the reason for your first trait, “A software prototype is developed in isolation.”
In fact many prototypes would benefit greatly from being plugged into existing frameworks and can only be demonstrated in a connected way. However, I think you threw in the “isolated” trait as a proxy for this trait: “A prototype must be presented and marketed to management or the client as a fake, a sham and a throwaway otherwise they’ll think you are _done_.”
I’ve found a number of ways to do that include “isolating” the prototype using mock interfaces and data as well as making sure that the UI is functional yet _ugly_. If done right, a prototype gives them a glimpse of what they’ll get if they continue to fund the full project.