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.
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" 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.