Demo-driven development

What is the safest way to fix a broken demo? Hide all bugs with local patches, as workarounds to special cases.

Handle only the specific circumstances seen by the demo; ignore other implications. Add special branches to the logic. Hide exceptions and errors that might reveal deeper problems. As long as side-effects are not visible in the demo, you will be congratulated.

If you try to clean up defective logic at the source of the bug, you might expose bad assumptions elsewhere. You do not want to spoil the next presentation, do you?

A demo follows a carefully planned "happy-path" "thin-thread" workflow through an application, with the same order, data, and options each time. You know where the demo will encounter the bug each time. Apply a bandage to the exact spot.

You can even pretend you are being Agile, because you are solving one problem at a time for a user. You have only one user who matters -- the one who gives the demo.

Unfortunately, real users can exercise the full application and try options in different combinations. A customer will rediscover any faulty logic.

When you ship, plan on a limited rollout to receptive "early-adopters" in a controlled environment. Think of it as a hands-on guided demo.

Bill Harlan, August 2009

Return to parent directory.