How to ship a prototype

In only two easy steps (and one hard one)

There is a wise adage in software development: “build one to throw away”. The idea is that as you are building, you learn things that change your initial approach to the problem. Intentionally create a toy version to test the problem domain, throw it away, and start over.

Who has time for that? Most software has a three-step road to success.

1: Prototype

Start on a new problem by writing some code to flesh out the idea. In a business context, this means typically writing mockups, clickable prototypes, or a sample program that does the absolute most straightforward version of what it needs to do. There is a common saying attributed to Kent Beck:

Make it work, make it right, make it fast.

This prototype will make it work, so it intentionally cuts many corners to get an initial version of the system up and running so that you can change it quickly. This version will avoid as many cross-cutting problems as possible to focus on the parts of the system that are new or unknown. For example, there is no database, the core computation likely returns the same number every time, there is no logging, there is no fundamental architecture, etc. A prototype of an invoice engine would produce the exact same invoice details on each run but may have a new approach to tax calculation. This program is “alive” but very stupid and not real, but it appears real enough so you have a framework to ask questions.

2: Feedback Demo

Once you get it into this compromised hand-wavy “working” state, where you have proven a few concepts you can build later, you show this to people. These people ask questions, and you answer them, learning more about the problem and how the final system should work, influencing how you would build the actual system if you get the chance. You also ask many questions about the customer, their expectations, and how the system will be used at go-live or in the future. You are likely asking more questions than they are, and you learn quite a bit from showing it to others.

You leave this meeting feeling like you learned a lot. You make a few pages of notes on how to rebuild everything based on the new information and a list of other items for deeper research.

3: Welcome to Hell

A few weeks later, you are either still working on the prototype or something else, and you find out that the prototype has been sold and are given a Hard Deadline, which you are now responsible for meeting. You recount the discussion in the meeting, especially the preamble, where you discussed all the smoke and mirrors, compromises, fake data, and hand-wavy assumptions you made to make it look like it was working so that you could ask questions. There may have been a simple misunderstanding; perhaps a key stakeholder was late to the demo.

You then find out that the session was recorded, that your preamble was cut from the video, that a professional voice actor has been added, and that the meat of your demo is now in a commercial for a product that needs to launch this quarter. You are shown a sales presentation with a large business funnel with the pointy end directed at your system. There was no mistake; your demo kicked off a series of events that led to this place.

This place is prototype go-live hell.

Now, you attempt to build an actual product from this stupid demo, a week at a time, trying to furiously erase the tech debt and compromises you made, blaming outside events when you are painted into a corner. Because the Hard Deadline is based on a sales cycle, it keeps moving around. Back 90 days, then forward 30 as customers say they are interested and then change their mind. An upcoming conference in which a completed initial product will be presented looms.

You participate in a series of meetings that you think are requirement-gathering sessions, but you soon realize they are negotiations. On the other side of the room are people who are coworkers on paper but professional negotiators working against you in real life. No customers are in the room, and each question you ask seems to, at some level, get one of two responses, “How long would that take?” or “What the hell are you saying, that isn’t in scope, stop talking so we can tell you what in scope is this week”.

You start to think Kent Beck was talking about your career, but you soldier on, eventually shipping a passable Version 1 with only a few features. Version 2 will be much better, so you start to work on it; this time, you keep your prototype to yourself.