My first really big presentation included a live demo with many moving pieces. Big time mistake – it crashed in a most spectacular fashion.
I’ve seen people make the biggest demo mistake of all times – hitting the “do it again and maybe it’ll work button” over and over and over and over (hit it once and have it fail – ok, hit it twice and have it fail – maybe. But that third and fourth time and beyond – sorry, you just lost me there). You need to be able to recover gracefully.
Anytime I go to “ad-hoc” something in response to a question – I tell the audience “we are no longer in demo land – we are in real life – this may or may not work”. Ad-hoc’ing a demo is like developing a new application – it may or may not work the first time around. My “demos” are my tested production systems. I have a special set of VM’s (virtual machines with VMWare) that I call my production instances. They are very carefully crafted and I don’t use them for anything but my demonstrations. Anytime I step out of them and use another environment (another VMWare machine – like the one I use to answer questions while on the road) – the demo’s invariably crash and burn. It just happened to me at the GOUG this week in fact! I was doing a live “AskTom” session and the question I received was most easily answered by example. I didn’t have my USB external disk plugged in so I just used my internal disk with my “answer questions” VM instances. They can be a mess since I just whip up examples and change things constantly. I started up the script and of course I immediately had name space conflicts to clean up (I really should be more original than to use T for tables, T_IDXn for indexes, P for procedures, F for functions and the dreaded V for views – htmldb (apex) users should understand why V is a really really utterly bad choice!). So I got the demo to work – but it was not as clean as it could be. Made a couple of jokes while cleaning up my schema to let the demo run – and then it did. (If it did not work the second time, I would have not gone for a third try)
At the same conference – I was watching another presenter, she was showing off Workflow. She got a question and ad-hoc’ed the response. Received a “404 Not Found” message during the process. Did not panic, went back – tried the process again, got the same error. Recovered gracefully – “it is just a demo, this is my laptop, not production, I won’t bore you by debugging this now” and explained what the process would be. Excellent. If you do live demos and ad-hoc them, the ability to gracefully recover and not get the “deer in headlights” panic setting in is crucial. Make a joke of it and continue.
I’ve always been skeptical of “large” demos I see on stage anyway. If we are looking at a graphical interface showing us stuff and just have to take it on faith that “stuff is really happening in the background” – I don’t see the point (might as well just screen cam it). I remember my manager back in 1995/1996 wanting to build “the coolest demo system ever”. We would run it like a production system – it would do thousands and thousands of transactions continuously, run parallel query – it would model an enterprise. I pointed out that to run such a “demo” system continuously would require staffing similar to running a “production” system in the same fashion (our demo systems are our production systems when we are on stage, think about that). I used the “chocolate world” analogy at that point. My thought was “this is a demo, it needs to work – it needs to work exactly the same every single time – it needs to work every single time – it needs to just work without any surprises whatsoever”. Chocolate world in Hershey park (near where I grew up – been there dozens of times) is a chocolate factory simulation. It demonstrates what they do in the factory. It is not a factory, it is a carefully crafted simulation of one. My concept for this demo system he wanted to build was “we should just get cardboard boxes, cover them with aluminum foil and blinking Christmas tree lights – those are the servers. Then explain how the software running on them would work in real life and show information from real systems”. Just like chocolate world. That to me is what a large scale demo should be about – trying to make it be 100% real, in an environment like you have when presenting (5 seconds to setup before hand – your laptop you use for “real life”) is a recipe for disaster.