Prototyping

I've been working on defining development processes for NHSBT and have been discussing useful forms of prototypes.

The way I see it there are two main classifications:

• User Interface Prototype
• Technology Prototype

One typically prototypes to communicate concepts to a user or to prove a technology.

I tend to use two types of User Interface Prototype:

• Wireframe
  
• Ghost Town
  

A wireframe prototype is used in most projects that have a UI. It is typically a set of drawings (electronic or paper) that show the layout and flow of the UI screens. It is great when you have experienced users who are familiar with a broadly similar application and can visualise the final functionality. It falls down badly when the users are unfamiliar with the type of functionality.

A ghost town prototype fills in the gap. The UI is implemented in actual code as a shell with no actual business logic or persistence. It is called a 'ghost town' because it is like the towns in western shows and films where the entire street is just a set of thin facades held up by beams and boxes. The UI is fully interactive and it makes it very easy for the user to grasp the functionality. Traditionally ghost towns were considered 'throw away'; nowadays with the Model View Controller pattern it is very easy to implement ghost towns where the majority of code can be reused. The only real drawback is that they can give a false impression to the user that the application is finished and ready.

There are also only two technology prototype forms that I use:

• Proof of Concept
• Tracer Bullet

The proof of concept is a purely exploratory prototype which is done to investigate a new technology. It follows a simple process of writing code and seeing if it works in the expected way. This prototype can be very dangerous if clear goals and criteria are not established early on as it can become very undirected and any decisions made as a result can become matters of opinion that may not be in the best interests of the wider project or programme. The proof of concept should always be written expecting to throw the code away as the technology being investigated may not be suitable; that does not mean that the code should be written as if it were expected to be thrown away. A poorly written proof of concept can be less than useless in evaluating a technology, also with modern refactoring a successful proof of concept can be turned into production code.

The tracer bullet is used when the choice of technology is well established but the particular technology stack has never been used before. A very thin vertical slice of functionality is selected that touches all the novel integrations and the prototype is written to implement it. This prototype should always be of production quality as the code it produces will define the patterns and standards for the finished application and will normally be the first check in to the development repository.

These are the types of prototype that I use on a regular basis, are there any that I should be using that I have missed?