A prototype has one job to do: Prove that it is feasible to implement your idea.
There may be additional benefits, like getting an idea which API or UI work, and which don’t. But at the end of the day, the prototype is to prove feasibility. Most importantly, a prototype is not the tool to convince stakeholders that your idea is a good one. That’s a non-technical issue, and therefore outside the domain of prototyping.
What is feasibility?
The American Heritage Dictionary defines feasible as “capable of being accomplished or brought about”. That isn’t quite what I mean, though. For a software project to be feasible, it has to be capable of being accomplished within constraints, namely time, effort, and thus money. That means that your prototype has to demonstrate that your idea can be brought about, and it has to inform you at least very roughly how much effort, and thus cost, is required.
What your prototype needs
For simplicity, I’ll assume that your idea is computationally feasible. That’s by no means a given, but understanding computability requires theoretical analysis of the problem you are trying to solve. A prototype will not answer that question, so here we only concern ourselves with cost estimation and efficiency.
The most important questions your prototype should answer are:
- How much of the use case can be covered by existing libraries and services, and how much do they cost?
If there are libraries and services you want to use, use them in your prototype, otherwise you will not know if they are fit for purpose. - How much code and infrastructure will you have to build yourself?
This is what’s left over after using all existing libraries and services. The holy grail here is to estimate this accurately. Nobody really has a good way to do this. My best practice formula goes like this: 1) Ask all engineers familiar with the project for their most conservative estimate, 2) take the longest of those estimates and double it 3) that’s the earliest time you will have a beta version to give customers to try. This formula is right about 50% of the time, the rest of the time, it underestimates, like every other method out there. - Where are the unknowns that the prototype does not cover?
These are things that are very hard to predict, but you vaguely know that they are there. For example, it’s easy enough to train an ML model on a restricted input set for a prototype. But training a model that is capable of meaningfully processing inputs at scale is a different problem altogether, and it is very hard to predict how long tuning will take and how much it will cost. These are largest contributors to project risk, and unfortunately, the prototype does little to help reduce that risk.
This information gathered from your prototype is the foundation of your project plan and budget. You might want to throw away the prototype itself, though. Most software projects attempt to build the “real” implementation on top of a prototype, to save time. That is risky, and I’ll discuss strategies for building re-usable prototypes and knowing when to discard a system in later articles. For now, just consider what is more costly: refactoring the prototype to the “final” architecture with all the details, or building it clean from scratch?
Lastly, do you need a prototype?
Almost certainly, yes. Same as no battle strategy survives enemy contact, no software project plan survives implementation. Things will go wrong, and you will have to adapt and change. Often significant parts of your plan prove infeasible during implementation. A prototype is your chance to test the feasibility of the most critical parts of your plan, and adjust before you invest heavily. Chances are that what you learn from your prototype leads you to throw it away and start the “real” implementation from a clean slate, but with what you already learned in mind.
Agile processes like Extreme Programming are often presented as embracing change to the extent that throw-away software is no longer a thing, and that the process is so flexible that you can adapt to anything along the way. From my experience, no practical process can achieve that. Applied judiciously, agile processes can reduce the risk and cost, but not fully alleviate it.
In the end, it’s up to you.
Required Reading
- Plan to Throw One Away, in Jr, Frederick Brooks. 1995. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition.
- Beck, Kent, and Cynthia Andres. 2004. Extreme Programming Explained: Embrace Change, 2nd Edition.