You’ve probably heard numerous times about the value of failing fast and prototyping. This post will try to frame the process of Prototyping and work as a starting point for a series of posts that will describe the flow From Assumption to Production or FATP.

What is a Prototype

According to wikipedia:

A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming.

Or according to my (somewhat strict) definition:

A prototype is a draft implementation that evaluates ONE and ONLY hypothesis

Prototypes exist only to test if the initial assumption was right and not to teach us things or evaluate technologies. The latter are by-products of most prototyping efforts but not what they are built for: they are build for evaluating assumptions

As soon as the initial assumption is answered the prototype is no longer useful. Of course parts of it (or sometimes the whole of it) can be used in later stages but this is never a requirement of the prototype.

Prototyping in context

As engineers we have a set of rules and good practices we live by: design patterns, separation of concern, reusability, you name them. In the prototype world however all of these go away because good practices take time and prototypes are meant to be fast.

Enhancing the previous strict definition (making it even stricter):

A prototype is a draft implementation that evaluates one and only hypothesis in the minimum amount of time

A hypothesis is a statement that includes a large risk and it must be treated as such. The longer it takes to build the prototype and evaluate the original hypothesis the bigger the risk.

Rules of engagement

The prototype world has its own set of rules and none of the basic rules apply. If there was a software bible with all good practices we know as engineers, the ‘Protype Gospel’ would be hand written and blessed by satan himself. Global variables? You rock. Code duplication? You’re the best. Messy, unstructured code? You’re the prototype GOD. Big methods with no comments? You’re going to heaven as a VIP.

Everything you know about programming goes away when you’re taking the big risks. Noone cares how carefully crafted or elegant solutions you came up with during prototyping if your initial assumption is wrong. Noone is waiting for the prototype, they’re waiting for the answer to the initial question.

MVS (Minimum Viable Scaffold)

Most prototypes require a supporting structure to work. It could be an ElasticSearch index, or missing data from your clients. In all cases, you want to minimize the work you put on supporting structure for your prototype. If you can make assumptions or use hardcoded numbers then do it by all means.

Consider the analog of prototyping a Computer Vision algorithm for robotics. Your scaffold, the actual robot, can be a cardboard box with lego wheels and coffee shaker motors. If your scaffold has newly developed arms, with newly developed wheels and motors, on a carbon fiber body running on experimental batteries made of recycled egg shells then you’re not prototyping.

Watch out for the signs

As engineers we can get carried away with the details and miss the signs that warn us we’re escaping the prototype scope. While writing this post, I had an idea of drawing a parallel to the world of quantum mechanics and how different rules apply in the quantum field. I started digging into quantum theory articles until I realized that I had drifted away from my goal: to write a post about prototyping (this paragraph is the only thing left from that pursuit)

There are signs everywhere that you are on the wrong way. Below is a list from my experience:

• Solving problems that might occur
• Premature optimization
• Any of the ACID acronyms
• Catching exceptions
• Pixel perfect designs
• Extensive documentation
• Integration tests
• Thinking of race conditions
• Solving problems of existing tools
• Copywriting

If any of the above ticks, you’re not prototyping.

You can still be awesome

Remember, prototyping doesn’t remove the joy of writing elegant code and providing smart solutions, it just postpones the need to a later stage when you’re absolutely sure about what you’re building. You will (almost) never have to remove your carefully crafted code if you prototyped earlier.