Tag Archives: prototyping

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 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.