Photo by Vitaly Gariev on Unsplash
Never do live demos.
(HT: Everyone Knows This)
Explanation
Do not do it. You probably will anyway, but you will regret it.
I hate technology. This is ironic since I have two degrees in computer science and have spent my entire career working to tame computers with software. I do not like working on or with computers despite the conveniences (not to mention monetary profit) they provide for me. The two aspects of computing that most perfectly capture my hatred of computers are:
- Printers and
- Live demos.
Printers are too sensitive of a topic. I refuse to talk about that subject.
For whatever reason, using a computer in front of others is like playing with live wires while standing in a pool of water or juggling molotov cocktails. It’s almost as if the computers have malicious intent even though I know, deep down, they don’t.
Newton Crosby: It’s a machine, Schroeder. It doesn’t get pissed off. It doesn’t get happy, it doesn’t get sad, it doesn’t laugh at your jokes.
Newton Crosby & Ben Jabituya [in unison]: It just runs programs!
Newton Crosby and Ben Jabituya, Short Circuit (1986)
However, it seems that no matter how many times you run through the demo in advance, something goes wrong. The reality is that software usually requires steps to be executed in a very specific order to work correctly and when you’re under pressure to deliver a demo, you usually forget something you’d normally remember. So, in my experience, it’s best to pre-record a demo and run it from the recording. Of course, then you have the problem that you can’t improvise if someone asks a question or wants to see a different path, so you often end up having to do a live demo anyway.
Oh, well. In IT, systems administration, software engineering, and the like, you either get used to looking like a fool on a regular basis and be humble about it, or…you find a different career.
Incidentally, many coworkers and my family constantly claim that computers are afraid of me. I think something like the live demo works in reverse under some circumstances. If I had a nickel for every time someone told me the computer was doing something wrong and then it didn’t happen when I showed up to help, I’d probably have enough to buy a couple meals at McDonalds. Still, that’s a lot of nickels.
In this case, what is happening is someone tried to do something, but forgot a step. In frustration, they keep forgetting the step. So whatever they are trying to do doesn’t work. They ask for help and, then, not wanting to be embarrassed, they are more careful and do all the steps correctly while I’m watching. Suddenly it works.
I have a very similar experience when asking coworkers for help. Often, I go to ask for help with something, sure that something is wrong. But in the process of writing out my question I make some statements and as I read my statements I realize that I haven’t actually proven some part of that statement is true. I go verify those facts and, voila, I discover that my problem is actually that I made a bad assumption.
This happens so often among computing professionals that we have a term for this: rubber ducking. We explain our problem to an inanimate object, like a rubber duck or teddy bear, (or write out the explanation into Slack chat or in an email) and in the process, we realize what the problem is. Very often, the actual work of trying to understand the problem reveals what the problem is.
That’s a lot of waffle and I have wandered from the subject, but during live demos, the opposite of rubber ducking is happening: you rush to do the work to show it without applying enough calm mental capacity to ensure that you are doing it correctly, even when you have a carefully written script in front of you.
So never do live demos. You’ll always screw them up. But, thankfully, you can always blame the computer because that’s what everyone else does anyway.
Cheers.