If I were to write a kind of How To Succeed In Business Without Really Trying kind of guide to giving demos of your research, it would probably include the following list of things to avoid:
- Infrastructure: the only time people notice the plumbing is when it doesn’t work, and the challenges involved are subtle and non-obvious. Stick with pretty interfaces that demo themselves.
- Multiple caches: Cached information can mask what’s really going on in a system and change the results from one demo to the next. This is even worse when some of those caches involve software that isn’t yours.
- Multiple threads: Multi-threaded applications are a bear to debug, and are a great way to introduce race conditions and deadlocks that invariably only pop up when you’re giving a demo to someone important.
- Anything involving networking: Networks are complex and cantankerous creatures that can fail for a number of reasons beyond your control.
- Wireless: That goes double for wireless. Especially since wireless acts differently when you’re in a room full of audience members who all have their own laptops out and broadcasting.
- Asynchronous communications: Throw in multiple machines (read: multiple potential failure points) where the same exact user action might produce different effects depending on the timing of how messages are sent and you’ve got a situation where you can successfully test the same demo 10 times in a row and still not know for sure if it’ll work on the 11th try.
Never one to take the easy route, my current research project contains every one of these features. No matter how many successful trials I run, I never really know whether this time it’ll go boom.