all systems are prototypes

Igor Ivan Sikorsky built and flew the world’s first multimotored aircraft, four years after he built a prototype helicopter.

‘God … created a number of possibilities in case some of his prototypes failed—that is the meaning of evolution.’ Graham Greene, Travels With My Aunt.

Two college dropouts raised $1,500 and spent 6 months in a garage designing the crude prototype for Apple I .

Howard Hughes flew the Spruce Goose, the largest aircraft ever built, across Long Beach Harbor at a maximum altitude of 70 feet. Hughes built it as a prototype troop transport, but the Pentagon rejected his design and the huge plane went into storage.

why prototype

When you think about it, almost all worthwhile information systems are prototypes: working systems that serves as a models on which later stages are based or judged.

So, why not build them that way in the first place? No multiyear development schedules and overruns. No monument building for eternity.

Like automobiles and helicopters and electric circuits and public buildings, almost all good information systems descend from prototypes or earlier production systems.

We know that most system failures arise from faulty requirements statements and faulty feasibility analysis.

We know that most of the effort expended to fix systems results from inadequately defined requirements.

So let’s test everything out small-scale and quickly, building and implementing prototypes.


  1. quick implementation (a few hours up to 3 weeks)
  2. live, real information, not demonstration data
  3. hands-on tool for communication between developers, intended users, and management
  4. usually not secure and robust enough to become a production system

necessary environment

Get the right prototype environment set up, then go.

  1. agree scope statement defining the activities and data to be prototyped
  2. agree criteria statement defining how prototype will be judged
  3. provide rapid-application-development tools
  4. provide one Developer, the person who builds the prototype system
  5. provide one Contact User, the representative user who explains the requirements to the developer
  6. provide additional user representatives to test and judge the prototype

what experience teaches

  1. Contact User must be a real potential user of the system being prototyped
  2. Developer should be expert in using the rapid-application-development tools
  3. user representatives should be aware that the prototypes are experiments, like preproduction models of next year’s automobiles.
  4. start by prototyping one significant part of the intended new system and get that approved before doing more
  5. developer should give what the contact user asks for (within the prototype scope)
  6. set aside time for intended users to experiment with the prototype
  7. don’t bother about technical issues such as access control since the intent is to learn user requirements
  8. The Developer and the Contact User should together define the scope and intent of the prototype.
  9. The contact user, in consultation with the developer, should define the criteria for evaluation.
  10. Management needs to understand, agree  and facilitate the whole project.


  • when a prototype is approved: user commitment and a clear understanding of the real requirements for the production system
  • when a prototype is rejected: quick way to learn not to build a production system for these requirements

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: