- Engineering Complexity
- Birth of Murphy for Java
- People = Problems
- Education Through Pain Management
- The Twenty-Cent Solution
- Fraternal Clones
- "We Lost the Napkin"
- The Devil in Blue Jeans
- Jack and the Beanstalk
- The Slashdot Effect
- The Funhouse Microphone
- That "New Car" Smell
- If I Can See It, It Must Be Wrong
- The Ugly American
- Murphy's Law
- Use Egg Cartons
"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.
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.
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).
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.