Prototypes vs Products

Why Making Things Work is Not Enough

At some point, every technical business has to make tough choices about the kind of work they want to promote and pay for. Time is money, as they say, and the longer something takes, the more it costs, right? It's easy to fall prey to the misconception that because a thing looks and behaves the way you want it to, that the underlying ideas, infrastructure and engineering that powers that thing don't really matter, and that the fastest-developed product is inherently the best. But as any competent engineer will tell you, that's a fallacy. Here's why.

First, if you haven't already, go back and read what makes some code better than other code. I'll wait.

Ok, now that we're all up to speed on some basic coding rules, let's talk about why quality in engineering is important. There is certainly a faction that will tell you that when you show your app to the CEO of your company, all she's going to care about is that it looks and behaves the way it's supposed to. What they don't tell you is that, in six months when version 2 of your project is behind schedule and over-budget due to the rampant instability, poor documentation and testability of version 1, she's going to be upset. And that's the result of poor engineering and code quality. It's also the difference between a prototype and a product.

Prototype vs Product

A prototype is a thing you might hire a consulting firm to build as a proof-of-concept and then throw away. Only the people who built it need to understand how it works, and the code that comprises it doesn't need to be pretty; that is to say, it doesn't need to be engineered with any particular standards or quality. A prototype is function only, so the guts don't matter. A product is a thing which you plan to release for consumption, and that you plan to improve and maintain over time. You put care and thought into a product, testing and debugging it and preparing for future expansion and change. A product is a thing that new engineers may have to be brought up to speed on; something that needs to be readable and employs standardized methodology that is accepted and vetted by a team of engineers or a community of them. These differences are the reason that prototypes are very difficult to turn into products. And also the reason that, if there is a chance that you want to be able to release something and then maintain and improve it, you should start building a product from the very beginning. It will take longer at first, but the long term gains far exceed the costs of releasing a prototype.

Engineers who disagree with this assessment are many, and they will argue until they run out of breath that when a thing works, it is done. To me, this is a telltale mark of inexperience, or perhaps a lot of the wrong kind of experience. Engineers who believe in the "works=done" paradigm are perhaps the biggest danger to your bottom line. While, at first, the speed with which they will be able to complete tasks may seem a boon to your schedule, there is an immeasurable and inevitable downside to this kind of work. Invariably, someone else will need to read and modify it, or it will need to be changed or improved, and every time that happens, your project will pay a time penalty for another engineer to figure out what the first was doing and how what was built actually works or is supposed to work. There is also always the looming possibility that so-called "prototype" engineering will simply need to be rewritten entirely. With work that emphasizes only function, you're happy only until you look at it.

That's not to say that prototypes don't serve a purpose. Prototypes can serve as fast evidence that a certain approach to a problem is sound, before applying that approach to an existing product. Prototypes can illustrate the different ways a product could work, so that product owners can make more informed decisions about the direction they want their products to take. There are plenty of reasons to develop a prototype, and once you have one, there's a very real temptation to keep it. But another fact about a software product is that, almost as soon as it's finished, it's obsolete. Keeping a prototype will handcuff you when you inevitably need to change things later.

The bottom line when deciding how development should proceed on your project is knowing what type of thing you're building. Prototypes have plenty of value as long as you know what you're getting yourself into. But as soon as you decide to release, scrap your prototype, and use the lessons you learned building it to make a robust, reliable and maintainable product.