An old friend of mine at my hackerspace introduced me to the concept of Prototype Zero: The Version that Even Your Own Sweet Mother Isn’t Allowed to See. The idea is that when you’re building something truly new, or even just new to you, your first take will almost always be ugly, and nothing will work the way it will by the time you make your second one. But it’s also important to the exercise that you see it all the way through to the end if you can.
I’m reminded of this after seeing a marvelous video by [Japhy Riddle] where he discusses his Prototype Zero of the Tape-Speed Keyboard. About halfway through the video he says that he would have done it totally differently if he knew then what he knows now: the hallmark of Prototype Zero. Yet he finishes it up, warts and all, documents it, and plays around with all of its possibilities. (Documenting it publicly isn’t part of the Prototype Zero method.)
I don’t think that [Japhy] is going to make a Prototype 1.0 out of this project, but I could be wrong; he seems to be content with having scratched the variable-speed tape itch. But if he did want to, he’s learned all of the gotchas on the engineering side, and found out exactly what such an instrument is capable of. And this loops back to the importance of getting Prototype Zero finished. You may have learned all of the tricks necessary to build the thing even before you’ve put the last screw in, but it’s when you actually have the thing in your hands to explore that you get the ideas for refinement that you simply can’t think up when it’s still just a concept.
Don’t be afraid to make your prototype quick and dirty, because if it ends up too dirty, you can just call it Prototype Zero. But don’t be tempted by the siren’s song of the 80% finished prototype either. Exploring putting Prototype Zero into use is its real purpose.
Oh my goodness, this PERFECTLY describes the very first “Arduino” project I did many, many years ago. I knew nothing about electronics but had seen a MAKE magazine in a bookstore, was curious, bought it, and studied every word of it. It definitely inspired me to learn more.
At the time, a friend was into collecting copper pennies (instead of the more modern mostly zinc ones) and so I decided to try to build a Rube Goldberg “penny sorter”. I built Prototype 0 and it actually worked. I mentioned it once in the Hackaday comments, and Elliot commented “would love to see that project!”.
Well, I think it might sort pennies at about the 1Hz rate so with Elliot’s past encouragement, I’ll see if I can get it on Hackaday.io before the deadline and get it submitted under the “Ridiculous” category. :-)
Anne Lamott wrote about this in “Bird by Bird” – a book about the craft of writing. She called it a “shitty first draft” that no one ever sees.
It’s time to retire that graphic. It’s clearly what HaD uses when the artist calls in sick :-)
No, the´ll reuse it ad nauseam just because they got the IP rights on it. It is their graphical lorem ipsum.
I have used this idea axiomatically as “you gotta do it once before you know how you should have done it”, for the last decade
So, a Proof of Concept?
Not quite.
A proof of concept is something you make intentionally bad and half-functional, because if you try to make a complete system that works, no matter how ugly, then management will put it straight to production without letting you build the actual prototype.
Arduino boards and every hack you did – every obsolete part you pulled out of your bin, and every circuit you cobbled together by hand without proper drawings or plans – that becomes the specification of the product, and your problem to source and support.
The prototype zero is the first version that integrates everything together, but is not yet optimized or field tested. Through testing, it’s supposed to yield prototype one, which is where the specifications are finally drawn and the biggest bugs are ironed out. That is what you then sell to the customers.
Management will skip testing and start selling the first prototype that integrates the system. That they call the “minimum viable product”. It comes back from the customers with complaints, and you have to split your effort between supporting the customers and designing the next version that fixes the problems. Mostly you’ll be putting out fires and trying to make the original prototype limp along somehow, and you won’t have time to design the better version. You have to develop it by incremental fixes to prototype zero while it’s already in production.
That’s why you never build a prototype zero. If you do, you never show prototype zero to anyone. You always build and test proof-of-concepts of the various parts of the system in isolation, with a Hintergedanke of the complete system, and you never reveal to management what the system is going to look like until it’s ready to be integrated with the bugs and the design flaws already ironed out.
That also applies if you’re building it for yourself. If you build the prototype zero, you get trapped into trying to fix prototype zero, because you’ve already built it and it would be soooo boring to start over entirely.
I see you have met my boss…
That’s every boss. The minimum viable product is supposed to gauge the market response and define the product by selling the beta version, but it doesn’t account for the case where you have to throw it back to the drawing board entirely.
What?
The boring part is nursing prototype zero into production when you know what needs fixing.
Then nursing it until you find a better deal and run away from that steaming pile of code.
That said, the real reason prototype zero sucks is the end users didn’t even know what it had to do until you made the problem concrete.
If you’re the end user, it’s tough to admit that you were the problem.
Also: There are ‘happen once’ problems where prototype zero is the solution, along with manual data fixes etc.
But that’s more the realm of digital janitors than real programmers.
You can outsource a solution, but the problem remains yours.
Remember that when someone acts like they paid you to own their problem.
No they didn’t, they paid you to solve a problem.
But once they’re done paying, not your problem anymore!
Also: Some bosses realize that crapping the bed with a beta will end their marketing efforts.
It really all depends on where the market is and how bad a worst case screwup can be.