This post is inspired from a personal experience that just happened very very recently. Fresh from the oven. I was demo-ing what the team has done to a few people and 5 minutes into the presentation *boom* ’˜Server Error'.

Nothing works.

So reflecting back on it, what can I have done differently to avoid this?

1. Rehearse

 

The most logical thing one has to do is to rehearse the demo. Don't take Demo lightly : it takes quite a significant effort to prepare a demo unless if it's a very very informal one. If that being the case I would argue a demo is unnecessary. Invite the person back to your desk, and show them in a relax ad hoc kinda way.

However if that's not a possibility, prepare a significant amount of time to get a script done, rehearse multiple times and don't forget to even rehearse parts of it on the venue/meeting room/conference where you're going to do the demo in. Try and avoid last minute rush due to broken monitor cable, slow internet connection, etc.

2. Reset

The first point (rehearse multiple times) may sound simple, but it's actually not. Most software behave differently with different sets of data. As you go through the demo script, you may be altering those very same data. How can you be sure that the demo script still works? You could simply try it again, but how can you be sure the next attempt the software won't crap out? (think things that could happen, duplicate validation error, log file reaches its limit, exceeding hard drive space, etc).

The only way to be sure that you can get a consistent behavior is to have a reset or rollback mechanism. Start from a known baseline. It's also as important to have this as automated as possible to avoid human error. If this is impossible to do then automate parts of it and document the steps in a document. Go through the pre-demo check list and remember to do them before you start the demo.

3. Isolate

So we've rehearsed the demo script, reset the environment and suddenly IT department just told you that Oracle database that you're relying on is down due to some other team buggy script.

We want to isolate a demo as much as possible. Run everything locally if you have to, or at least put it on a server where a known set of people have access to. Send them an email to remind them that you'll be doing a demo in the next 2 hours and expect them to not use the server.

4. Don't touch

Once you've done all you can to prepare for the demo, don't touch anything. Yep, I really mean anything. That nice to have feature that you think you can get done in 5 mins and won't affect anything? FORGET ABOUT IT. You said it yourself IT WON'T AFFECT ANYTHING.

Tell your audience that you've got some known defects and you're already working on it but not included in the demo. Keep the version stable and leave the new unstable feature for the next demo instead.

5. Fingers crossed

Things that can go wrong will go wrong. And sometimes all we need to do is keep our fingers crossed to the demo gods. It doesn't mean that you shouldn't have plan B and C in your pocket should you need it. Show the audience screenshots, or video of your rehearsal demo.

But when things do go awry (if what you're demoing is the integration piece and the server fails to respond), be calm, apologize and reschedule. Make sure you don't repeat the same mistake twice.