Throwaway prototyping

With Throwaway Prototyping, code is developed to explore factors critical to a system’s success and then that code is thrown away.

The prototyping implementation uses programming languages or development practices or both that are much faster than the target languages and practices. The user interface is prototyped far more commonly than any other part of the system but other parts of some systems can also benefit from being prototyped.

When used as a requirements-specification aid, the Throwaway Prototyping practice can accelerate projects based on traditional lifecycle models such as DoD projects. It can be initiated at either a management or technical level.


  • Potential reduction from nominal schedule: Fair
  • Improvement in progress visibility:  None
  • Effect on schedule risk:  Decreased Risk
  • Chance of first-time success:  Excellent
  • Chance of long-term success:  Excellent

Major Risks

  • Keeping a throwaway prototype
  • Inefficient use of prototyping time
  • Unrealistic schedule and budget expectations

Major Interaction and Trade-Offs

  • None

The Throwaway Prototyping practice derives its development-speed benefit from the fact that it is often possible to explore individual requirements, design and implementation options using languages and practices that allow for more rapid development than the ultimate implementation language and practices do.

Here are some examples:

  • We need to compare approximately how long it will take to store and retrieve 10,000 records using several different DBMSs, so we write throwaway code to exercise the DBMSs and to compare their performance.
  • Our end-users can not decide between two user-interface styles, so we mock up two user-interfaces using interface-building tools and give the users a “live” demo without ever writing a line of code.
  • We want to check the feasibility of communicating with another application before basing our future design decisions on that ability, so we write test code to verify that such communication is possible. The test code contains no error checking and does not handle any exceptions, and we throw it away as soon as we have verified that we can communicate the way we need to.

We can employ Throwaway Prototyping at any time in a project – to clarify requirements, to decide an architectural issue, to compare design or implementation options or to test a performance optimization.

Using Throwaway Prototyping

Throwaway Prototyping can be used by any of the project’s personnel. Individual project participants can realise some benefit by prototyping risky areas within their individual areas of responsibility

Here is a list of areas that can benefit from being prototyped and suggestions about how to develop prototypes in those areas cheaply:

  • User Interface
    Prototype using a prototyping tool or visual programming language or build a Hollywood facade in the target programming language.
  • Report Formats
    Prototype using a word processor or report formatting tools.
  • Graph Formats
    Prototype using a drawing tool or graphics library.
  • Database Organization
    Prototype using a database design language, 4GL or CASE tool.
  • Database Performance
    Prototype using a language design language, 4GL or CASE tool.
  • Accuracy and implementation of complex calculations
    Prototype using a spreadsheet or math-oriented language such as as APL.
  • Time-critical parts of real-time systems
    Prototype using a small test program in the target programming language.
  • Performance of interactive systems
    Prototype using a small test program in the target programming language.
  • Feasibility of parts of the system that are pushing the state-of-the-art or with which the development staff has no experience
    Prototype using a visual programming language, small test program in the target programming language or math-oriented language – whatever is appropriate.