Prototyping is a fundamental part of agile development, lean startups and growth hacking, because it’s the best method to crunch a lot of knowledge in a short amount of time. However, I’ve often seen it slowing down development in the long run.
Talking About Prototyping
Whenever we decided to use prototyping, we’ve talked about it in the same way. A developer would say something like: “Let’s just quickly throw some code together and put a prototype out there!”
We usually all agreed without ever talking about an important detail: What would happen with the prototype afterwards?
Well, it was obvious to us that the quality of the code would be below our standards. Thus we all assumed that we’d throw away the prototype and rebuild it properly at some point. Admittedly, the reality looked quite different.
Shortly after collecting the initial feedback from the prototype, we would then decide to make some adjustments and validate another assumption with it. After a couple of these iterations, the prototype usually evolved into an early version of the actual product.
Although this reads like the story of a great success, there’s a huge problem.
When building throwaway prototypes, we would always sacrifice quality for the sake of development speed. This is only acceptable as long as we throw the code away afterwards. But as we started iterating on the prototype, we made this low quality code the foundation of our new product. The result: a big ball of mud that would slow us down significantly.
Building A Strong Foundation
I’ve come to the conclusion that throwaway prototypes are not a good idea at all. We tend to iterate on prototypes anyway, so why not embrace this fact and invest at least some time into quality?
Sure, we have to find the right balance between quality and initial speed, but investing into a flexible foundation will be worth the effort.