Build Prototypes

...you are trying to gather requirements necessary for test planning, as in the pattern ApplicationDesignIsBoundedByTestDesign, and for the architecture, as for the pattern ArchitectAlsoImplements. Some of these requirements come from the customer, but some are design decisions that come from the structure of the solution itself. For example, you may be building a user interface, some new technology such as database or network technology, or you are working on a new, critical algorithm, or don't understand your project domain.

✥ ✥ ✥

A project must test requirements and design decisions to reduce the risk of wasted cost and missed expectations.

You need knowledge to proceed on development, and you must move forward; yet, requirements (or your understanding of them) are always changing. 

You're missing information about the product (not the process), and you have a best guess you can use to move forward, and you want some way to evaluate the result of your best guess. 

Written requirements that are gathered once at the beginning of a development cycle with the hope that they can drive development are usually too ambiguous. 

You want to get requirements changes as early as possible, and you want requirements understanding to lead deployment by as far as possible. 

Designers and implementors must understand requirements directly -- that the requirements have been captured in a document isn't enough. And for designers and developers to understand requirements implies that they must understand the implementation ramifications. 

Therefore:

Build an isolated prototype solution whose purposes are:

• to understand requirements, including latent needs,

• to validate requirements with customers as in EngageCustomers;

• to explore human/computer interactions for the system,

• to explore the cost and benefits of design decisions.

The prototype is a small system that explores a small number of issues in isolation using best current knowledge. By examining that small system you can learn whether your current knowledge is correct and sufficient. Prototypes are particularly useful for external interfaces. 

Throw the prototype away when you're done. This is more important than it may sound. Since the purpose of prototyping is to gain knowledge, prototypes can (and should) ignore details necessary in production software. Yet such details (such as scale, performance, robustness, etc.) cannot be incorporated into prototype-based software without the result resembling the proverbial bowl of pasta. 

✥ ✥ ✥

You will decide that your current knowledge is or is not sufficient. If it is, adapt that small system's design (not code!) to your larger system (incorporate it entirely if it was built to production specifications). If not, decide whether you now have enough information to safely proceed, or whether you need to do another Prototype. 

It's good to use DevelopingInPairs, particularly if one of the pair represents the customer interests or is a customer per se. 

Prototypes are a good supplement to use cases to help more thoroughly to assess requirements. For one thing, prototypes help bring unstated requirements into the open. This pattern nicely complements EngageCustomers and ScenariosDefineProblem. 

The processes of the visualizations used for DeveloperControlsProcess, and the pattern EngageQualityAssurance, are based largely on prototyping. 

Continued prototyping without convergence means that the design is constantly shifting, and the team is not learning enough to reach a conclusion. If other teams that depend on the prototyping team do not get the stable interface they need, it is time to get out of prototyping and either implement or EngageCustomers (RecommitmentMeeting) to evaluate current project directions and priorities. 

There are subtle organizational overtones to building prototypes. It is important that the ArchitectControlsProduct, and not the prototype control the product. Therefore, the prototyping team should be kept separate from the Architect and ArchitectureTeam. Instead, the prototyping activity helps enhance the DomainExpertiseInRoles. And one of the positive effects of building a prototype is to reduce the risk of the unknown. The prototype helps to define the scope of the problem as well as a possible solution. 

Related patterns:

• EarlyAndRegularDelivery - adds knowledge about your development process.

• MicroCosm - returns measurable data about process and technology.

Another related pattern is Alistair Cockburn's ClearTheFog [BibRef-Cockburn1998], which one might view as a generic version of this pattern. In that pattern, Alistair recommends "Do something (almost anything) that is a best initial attempt to deliver some part of the system in a short period of time" in the interest of SomeoneAlwaysMakesProgress. He gives as rationale, "The difficulty is that you don't know what it is that you don't know. Only by making some movement can you detect what it is you don't know. Once you come to know what it is you don't know, you can pursue that information directly." And he adds an interesting admonition: "If you only 'clear the fog' and 'clear the fog' and 'clear the fog', you will not make real progress. You will have lots of little experiments and no deliverable results." 

Bruce Whitenack's RAPPeL pattern language also presents a ProtoTypes pattern ([BibRef-Whitenack1995], p. 288). He adds the admonition: 

The dark side to prototyping is that solutions can be hacked together with the software inadequately robust and not well designed. It takes maturity, discipline and a very good programming/design environment to reengineer quality back into a product. Without rigor and discipline a product is in serious risk of failure when features are continually added. As more prototyping and evaluating are done, there will be the need to modify the requirements. Iteration between prototyping and use-case modeling occurs during requirements analysis. In addition, user expectations have to kept realistic as a prototype is not a product. Customers must realize that what they are seeing is a product simulation — not the product itself. 

He also distinguishes between lo-fidelity prototypes and hi-fidelity prototypes: 

Work with the customer to build (initially) low-fidelity prototypes... using paper widgets, drawings, self-stick notes, and index cards. (These are true throwaway prototypes). Or, if the necessary skills and tools are available, build high-fidelity prototypes. (You do not want to spend more that 10 percent of your time on how to use the tool instead of focusing on the actual prototype, however). Alternate between prototyping and use-case modeling. Prototyping provides more user involvement, and use case modeling provides rigorous analysis. Augment the use case documentation with references to prototype versions (product simulations). 

The high fidelity prototypes that are developed with a tool capable of generating useful code may be used for evolutionary development. It may not be a throwaway prototype but should be developed with the spirit that it will be thrown away. This means making sure that all on the project — especially managers — understand that the prototype may be thrown away. It has been my experience with Smalltalk development that if the developer has a good design in mind and if he is experienced, the prototype will probably contain code that is very usable for a production version. Be sure to plan for training of beta users and for doing a number of prototypes for perspective users. 

Building and demonstrating prototypes is an art in itself. See the excellent pattern language, "DemoPrep," by Todd Coram [BibRef-Coram1996] for guidance on the building, administration, and demonstration of prototypes. See also an earlier work by Ian Graham [BibRef-Graham1991]. 

The risk to your project of a small, throw-away effort is a small schedule delay. The risk of making a poor technical choice is a poor product, or perhaps committing to a technology that simply will not work. 

Be careful not to be seduced by the siren song of a successful prototype. Prototypes almost never can demonstrate capacity, reliability, or performance. But these are often the most troublesome issues in development. The danger is that we see a prototype working, and naturally assume that it will scale gracefully, will run for weeks without rebooting, or will perform nimbly under a typical customer's load. A working prototype does not imply that these problems are solved. 

Contrast this pattern with SkunkWorks, which many think of as prototyping on a larger scale, but which is actually a little bit different in its forces and intent. 

"The best friend of the architect is the pencil in the drafting room, and the sledgehammer on the job." — Frank Lloyd Wright, quoted in [BibRef-Jacobs1978].