Build Prototypes

If early acquired requirements are difficult to validate without testing, then build a prototype, whose purpose is to understand requirements.

## Relationships

### To be applied before

* Build Prototypes is an instrument for Named Stable Bases.

### To be applied after

* Developer Controls Process is based on Build Prototypes.
* Continued Build Prototypes leads to Recommitment Meeting.

### Alternatives

* Get On With It
* Size The Schedule

*Contents of following sections belong to the original Organizational Patterns website[1] and have been divided into following parts: Context, Problem, Solution, Discussion.*

## Context

...you are trying to gather requirements necessary for test planning, as in the pattern Application Design Is Bounded By Test Design, and for the architecture, as for the pattern Architect Also Implements. 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.

## Problem

**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

## Solution

**Build an isolated prototype solution whose purposes are:**

* **to understand requirements, including latent needs,**
* **to validate requirements with customers as in Engage Customers;**
* **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.

## Discussion

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 Developing In Pairs, 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
Engage Customers and Scenarios Define Problem.

The processes of the visualizations used for Developer Controls Process, and the pattern Engage Quality Assurance, 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 Engage Customers (Recommitment Meeting) to evaluate current project directions and priorities.

There are subtle organizational overtones to building prototypes. It
is important that the Architect Controls Product, and not the
prototype control the product. Therefore, the prototyping team should
be kept separate from the Architect and Architecture Team.
Instead, the prototyping activity helps enhance the Domain Expertise In Roles. 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:

* Early And Regular Delivery - adds knowledge about your development process.
* Microcosm - returns measurable data about process and technology.

Another related pattern is Alistair Cockburn’s Clear The Fog [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 Someone Always Makes Progress. 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 ([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, “Demo Prep,” by Todd Coram
[Coram1996] for guidance on the building, administration, and demonstration of prototypes. See also an earlier work by Ian Graham [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 Skunk Works, 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
[Jacobs1978].

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html