Home > Articles > Programming > Java

  • Print
  • + Share This
From the author of

"We Lost the Napkin"

Law: A design always looks better on paper.

Q: Is there a functional prototype?

There are several problems with designing on paper:

  • Correctness is hard to prove.

  • The design of user interfaces is difficult to convey to users.

  • When there is more than one solution, it's difficult to prove on paper which solution is better.

A prototype can help developers learn about new software and experiment with solving the current problem. A prototype can also be used to prove that a concept is viable. Prototypes are important as an initial benchmark to use as a measure of future development success. Prototypes are the ultimate in requirement validation because a good prototype implements the most critical aspects of a product's design.

Low Risk

  • There is a functional prototype, and it uses live data!

  • Users have used and approved the prototype.

  • The prototype implemented the high-risk areas of the software and has eliminated key risks and uncertainties.

High Risk

  • No prototypes are planned as part of the development cycle.

  • We have a prototype, and we will just add a little more and deliver it to the customer (in other words, possibly hacked and buggy code).

Risk Management

  • Plan to throw the prototype away. Most prototypes are created quickly, without regard to quality or standards.

  • Use rapid prototype tools and buy libraries that can decrease the time from concept to prototype.

  • Keep prototypes simple. Don't implement more functionality than is necessary to prove the concept.

  • Try to design most of the look of the user interface. The worst bugs are those caused because the customer is unhappy with the usability of the software.

  • + Share This
  • 🔖 Save To Your Account