TL;DR Prototyping is an essential way to determine the technical feasibility and functional desirability of features of a software system. There is a clear and present danger that the prototype is considered to be professional code, peer reviewed and production ready. This risk must be mitigated and anyone involved needs to be very aware of what a prototype is and even more of what it is not.
A prototype of a car is typically easily recognized for what it is. It has no engine or lacks all kinds of details. Or it is clear at least that it was largely hand built and no production line is set up for mass producing it. A prototype of many products will be rough around the edges – not suitable for real life usage or at least not for production at scale.
A software prototype however is not so easily recognized at first glance. The UI is showing in the browser, it responds to mouse and keyboard interaction and there are no sounds or smells are rough edges that suggest this software is far from ready for real life usage. Anyone not intimately involved with the development of the prototype can easily forget that what they are seeing is not almost done. It may walk and talk like a duck – it is not a duck! Just like a movie town with just the facades of buildings it not an actual town, even if it looks like one in the movie, a prototype is not a real application
Why is it important to point this out [over and over again]? This is because temptation proves too great in many cases to not use a prototype for what it is – but to promote it to production status. Or at least to allow yourself to believe that everything the prototype can do is implemented for real. That expectation subsequently seriously skews any discussion on planning for the proper implementation.
What is a prototype (good for)?
Do not get me wrong: I am all in favor of prototypes. Prototyping is a great way of exploring what the technology at our disposal or that we are contemplating can do for us. And to demonstrate to end users and stakeholders what the implementation of desired features could look like. A prototype helps to understand the challenges to be dealt with and provides insight into possible solutions. It helps us with creating a functional design for the features desired by our stakeholders and allows us to make estimates regarding the effort of a real, production grade implementation. A prototype is a reference during discussions – it helps turn abstract ideas and conversation into much more tangible discussions and decisions. But a prototype is not the real thing. It is not proper software.
I have fallen into that trap myself. I am currently working on a prototype – an extended version of the ThoughtWorks technology radar. I have been adding various features – such as different colors and shapes and sizes for the blips on the radar. And the option of positioning blips outside all rings (pending evaluation). And the blips can be repositioned through dragging and droppping. A context menu can be used to select colorm, size and shape for any blip.
Instead of abstract shapes, logos can be displayed. Double click and a details window is shown with data on the blip:
And I have even more features added to my prototype.
Of course, in my enthusiasm, I have started to demonstrate my extended radar prototype to colleagues. And this created expectations. My peers expect to be able to start using the extended radar in the very near future. And of course that is what I want as well. It has almost led me to believe that my software is almost ready to be released into the wild.
But that is wrong. What I have created is something to talk about. And some proofs of what can be done. And some insights in how it can be done. I know now how D3 and SVG work. And I believe I understand how I can add dimensions to the radar and dynamically switch dimensions.
What is a prototype?
What a prototype typically is (and certainly is in my case): a one person job. Code that is understood by one person – at this moment in time. It is patchwork, cobbled together, bolt-ons on bolt-ons, many copy-and-paste code snippets from StackOverflow and other nooks and crannies on the internet. It is working code (sometimes just barely) but by no means clean or professional code.
Typically, prototypes are hardly or not at all supported by automated tests. They typically contain hard coded magic strings and numbers. They contain left-overs from experiments – tentative forays into code areas that were abandoned. There will be commented out code (that should be removed) and still active code that does not really do anything. There will be code comments about intermediate assumptions and mid-trial frustrations. The code is usually not hardened at all. Non-happy code paths have not been worked out, exception handling is limited and performance has not been top of mind to say the least.
The prototype has not been peer-reviewed. There is no guarantee that any other developer will be able to make heads or tails of the prototype code and if the developer themselves is at all like me, they probably quickly get lost in their own code. Proper coding was never the objective. Getting things sorted out and creating things to demonstrate were top of mind in the prototype.
To see a prototype that lives up to this description – go to my GitHub Repo for the extended Technology Radar. It is working software, which is good. And it is horrible in terms of the code. Which is okay for a prototype. But bad if you would even consider using it for real.
What to do with the prototype?
By all means – get inspired by the prototype. Use it to discuss features with stakeholders.
Also: use the prototype code as a source of inspiration. To see which cloud mechanisms are useful. To learn which libraries and APIs are appropriate to use. To get a feel for the approach and for the effort. If the prototype can do it, we can do it. And we already know how.
And then: start coding from scratch. Do not use any code from the prototype in the actual implementation. Even though this may feel wasteful – and of course you can copy and paste the occasional line of code – it really is best. Prevent sloppy code (and assume that your or my prototype is sloppy code) from getting into your main application code base and into production.
Production code should be Professional (or Clean) Code. That means code that is guarded by unit tests, code that is compliant with static rules regarding naming, complexity, programming constructs, that is reviewed and adopted by peers beyond the original developer for maintenance and further evolution. Code that is operable and observable. That is implemented using current technology, complies with security guidelines and can scale as is required.
My prototype does not qualify in any of these areas. And most prototypes do not.
Prototypes are not meant for production usage, they are not production ready. No matter how cool and complete they may see. Period.
Note: I hope to create a proper, production ready version of the technology radar and make it available on GitHub after proper peer review and when compliant with other demands for production ready, clean, professional code. When I have lifted the current prototype (working code) to professional code.
Afterthought on Minimum Viable Product
I have been asked if prototype and MVP (minimum viable product) are not more or less the same thing. I hope that from reading my article it is abundantly clear to you that they are most certainly NOT the same thing. Far from it. A prototype could be rich in functionality — much richer in fact than an MVP — but whereas an MVP is destined for production usage, a prototype should not be allowed anywhere near production. An MVP is viable. It lacks in features, it may lack in non functional characteristics (suboptimal performance, shaky robustness when it comes to corner cases) but it is professional code. It is a strong foundation onto which the next iterations of the product can be built. The prototype is quicksand. (now that I think about it, the parable of the wise and the foolish builders (see Wikipedia) is perhaps a good way to compare prototype and MVP.
Some other terminology: PoC or Proof of Concept is a project focused on demonstrating a certain concept. The concept can be a functional one — can we support a business activity with features of a software application — or a technical one — (how) can we implement this feature or will this combination of technologies allow us to achieve our aims. And the product of a PoC is typically a prototype. A demonstration model. (and of course not production ready code).
