Tenet 3: Build a prototype as soon as possible

3.2 Tenet 3: Build a prototype as soon as possible

When we say "as soon as possible," we mean as soon as possible. Post haste. Spend a small amount of time planning the application, and then get to it. Write code as if your life depended on it. Strike while the computer is warm. You haven't a nanosecond to waste!

The idea runs counter to what many would consider "proper engineering methodology." Most have been told that you should fully design an application before embarking on the coding phase. "You must write a functional specification," they say. "Hold regular reviews to ensure that you're on track. Write a design specification to clarify your thoughts on the details. Ninety percent of the design should be done before you ever fire up the compiler."

These guidelines sound fine in principle, but they fail to place enough emphasis on the prototype. It is in the building of the prototype that the idea is first tested for merit in a visual, realistic way. Before then, you have little more than a collection of thoughts about the way something ought to work. The concept is barely understood at that point, and it is highly unlikely that everyone perceives it in the same way. You need a consensus of perception before the project can proceed. The prototype moves toward that consensus by providing a concrete representation of the goal.

3.2.1 Prototyping is a learning process

The sooner it begins, the closer you will be to the released product. The prototype shows you what works and, most important, what doesn't. You need this affirmation or denial of the path you've chosen. It is far better to discover a faulty assumption early and suffer only a minor setback than to spend months in development meetings unaware of the Mother of All Design Flaws waiting to ambush you three weeks before the deadline.

3.2.2 Early prototyping reduces risk

Suppose you have something concrete that you can point to, and say "It's going to look like this." If you can show it to trusted users to get their reactions, you may learn that your design was on target. More often than not, your prototype will come back shot full of holes. That's OK, though. You have gained valuable design information. It is better to weather the ripples of a small group of critics than to hear a million users screaming for a recall of your product.

For every correct design, there are hundreds of incorrect ones. By knocking out a few of the bad ones early, you begin a process of elimination that invariably brings you closer to a quality finished product. You discover algorithms that do not compute, timings that keep missing a beat, and user interfaces that cannot interface. These trials serve to winnow out the chaff, leaving you with solid grain.

Most people agree that prototyping has many advantages. Even the academics who teach more traditional software engineering methodologies readily recognize its value. However, the prototyping is a means to an end, not the end in itself. The goal of all prototyping should be to build something we call the Third System. Before we can talk about the Third System, though, we need to talk about the two systems that came before it.