Practice6.Prototyping

Practice 6. Prototyping

Making a conscious effort to prototype solutions to risky problems helps to increase the chance of having a working product. Prototypes are an inexpensive way to try out ideas so that as many issues as possible are understood before the real implementation is made. There are two main classes of prototypes that you can use to positively impact your product. The first is the true prototype, where a test implementation is used to understand a problem before it is implemented for real. The second is the notion of "tracer bullets" [Hunt and Thomas 2000].

Reducing risk is a key part of working software. You need to continually assess risk in collaborative planning sessions, but, most importantly, when key risks are identified, you need to do something as early as possible in the project to ensure the risk is well understood. Prototypes are an extremely effective and relatively inexpensive way to evaluate risks. Not only do you gain an understanding of the nature of the risk, you have a prototype of a solution to the problem and hence have much greater confidence that you understand the length of time required to address the problem. You also have an implementation you can borrow from, even if it is only ideas, when implementing the complete solution.

Prototypes Don't Need to Always Be Software

I once worked on a project where we used a large number of prototypes, and few of them were implemented in software. Very early in the project we found ourselves struggling to provide an interface that our target users could easily understand and learn in a couple of minutes. Our first attempt was implemented in software, which took us several weeks to implement. After getting a few users to try out the software, it was painfully obvious that we had gotten the interface horribly wrong. It was confusing and required users to learn the quirks of the software not work naturally. We wanted to try again but were afraid to do so because we felt that:

1. It would take the same amount of time to implement a new prototype.

2. After our first experience, we had little confidence that we could get it right the second time.

3. We felt that anywhere from two to ten more attempts might be required to get it right.

For this problem, we were lucky enough to have an excellent usability person on the team. She suggested that we try out a whiteboard and paper prototype, so we spent a few hours laying out the interface on a whiteboard and putting together a number of large sticky notes for buttons, pull-down menus, etc. Then we asked some users to work through a sample problem while we manually made sure that the whiteboard interface updated in a realistic way. It took us a few more of these prototypes to find the optimal solution, but this took us only a couple of days. I suspect we saved ourselves more than two months of engineering effort!

Throwaway Prototypes

A throwaway prototype is an excellent tool to evaluate risky features and develop better time estimates for a feature. As explained in the "iterative development" section, the elimination of risk as early as possible in a project is often a critical project success factor. Doing a quick prototype in a small number of iterations is often an excellent way to acquire a much better understanding of the problem and the actual risk. Also, by developing the prototype as a throwaway, usually in a copy or branch of the product or a simple prototype application, it is easy to ensure that the product is still in a working state when the real solution to the problem is implemented.

Quite simply, a prototype is a quick and dirty implementation that explores key target areas of a problem. Prototypes should not be production ready, nor should they provide a complete implementation of the desired solution. They might even be implemented in a scripting language like Python or Ruby to save time. The bottom line with prototypes is that they should be used as a point of reference only when implementing the complete solution to a problem.

One of the downsides of prototypes is that you often have to show them to customers and management in order to demonstrate progress. One of the conclusions your audience could draw, if you are not careful, is that the problem is solved and done when, in fact, all you have is a rough proof of concept. If you do show a prototype to customers, be sure they know what you are showing them before you show it to them to avoid situations where your audience thinks the problem is solved. You could also make it obvious through rough visual output that clearly does not look done.

A good analogy to use is car design. The car manufacturers all regularly produce concept cars to try out ideas or demonstrate a proof of concept. These cars are one-offs that could be turned into a production version fairly quickly, but they are definitely not ready for shipping to customers. Likewise, many product designers ensure that if they are showing a digital prototype such as a rendered image to their clients that the image does not make the product look done. If you suspect there is going to be pressure to use the prototype for the shipping product, it might be better to consider using tracer bullets instead.

"Tracer Bullets"

"Tracer Bullets" are a deliberate approach that uses a prototype that is intended from the outset to gradually turn into the final solution [Hunt and Thomas 2000]. The analogy is combat: Imagine you have to shoot at and hit a target in complete darkness. The brute force approach would be to point your gun in the right direction and hope for the best. However, a more effective approach is to use glowing rounds called tracer bullets. You start by firing a few tracer bullets and then correcting your aim until you can fire real bullets to destroy the target. In the real world, tracer bullets are every few bullets in a clip. Hence, the software analogy is that if you're uncertain you're pointing in the right direction, start by building a viable prototype and keep adding to it until your customer says, "That's it!" This is really a microcosm of agile development, where multiple short iterations are used to continually add to a prototype. The difference is that agile development is applied to a collection of features (a whole product) and tracer bullets can be used on one feature, problem, or area of risk.