JSFoo: round the year submissions

Live demos are tech talks’ flakier, meaner older sibling. Yet it is undeniably the most compelling way to illustrate your message in minimum time.

I’m going to talk about my process for building a fortress around the code that I am demoing. If I’m going to get up in front of an audience I want to know that I am in complete control of my fate. We don’t always get to jump in the shallow end first, and as a relative beginner to public speaking I have found it crucial to carve out a comfortable space for myself to grow.

I’m going to talk about a keynote demo I did in front of over a thousand people. I will do the demo, then together we will go through everything that could possibly go wrong, from shaky conference wifi to unpredictable caching. I will also discuss contingency plans and what to do when things actually do go wrong. Beyond demoing, this is a extremely valuable skill for engineers that can be applied to writing excellent tests and designing robust systems.

Outline

Introduction

1. A few weeks after joining my current team, I was asked to give a short live-demo during the keynote of my company’s annual European conference, MongoDB Europe.

   • The demo that this talk is based on can be found here, at 7:20. The version of the demo I’ll do as an example in this talk will be shorter.
   • I love giving talks where I go into why a bit of code is super elegant or clever, but live demos are the opposite of my comfort zone.
   • On <speaking.io>, Zach Holman writes “live demos are like Global Thermonuclear War, the only way to win is to not do a live demo.”
   • I’ve seen, time and time again, that if there is any chance of something going wrong, it will go wrong.
     • Computers can sense fear: everyone has had a bug that haunts them, then as soon as your coworker is over your shoulder, it goes away.
     • I’m going to call it the “Other-People-Are-Looking-At-Your-Screen Factor”. Open to better names!

2. Why are live demos awesome?

   • There’s a reason people still do live demos, even though we all know better. The reason is that a live demo is live!
   • Programmers are scientists, and scientists want proof. This liveness can convince even the most skeptical audience member that what you’re doing is magical.
   • This is why people like Bill Gates and Steve Jobs do live demos, even when they go wrong.

3. I’m going to talk about why I “faked” my demo. I put fake in quotation marks because I’m not adding imaginary features to my product, what I’m doing is systematically going through my demo and removing even the most remote chance of things going wrong. A better word would be “mocked”.

   • I’m not going to argue that everyone should/should not mock aspects of their live demos because everyone’s lives are different and you just have to do what makes you feel best.
   • I know me, and what makes me feel best is feeling in control of my destiny. Database demos involve many different components, some of those things are networked and some of those things involve uncontrollable variables.

The Demo

1. I start with the real demo, using all live everything. Clearly that must work first.

   • Then I go through each piece of the demo and ask myself, “What could go wrong? Are there any uncontrollable variables involved here?” I don’t care if it’s unlikely, I don’t care if not that bad if it does go wrong.
   • Hint: if it involves any network, it’s probably gotta go.

2. To give you an idea of what I’m talking about, I’m going to do the exact demo for you: Abridged Compass tour (4 minutes)

3. So there you go. Kind of painless right? WRONG! What you’re looking at is roughly two weeks worth of work. I could do this exact same demo with real data, in real time, and it would look exactly the same. But I would be sweating profusely, convinced I forgot to start the server or drop my database, and completely miserable.

The Life-Proofing Process

1. Let’s start with the charts.

   • Since conference wifi is notoriously tricky, I’m going to eliminate network completely. Which means I now have to:
     • Run my server locally. However, since the charts are server charts, a server with no load is not particularly interesting-looking.
     • This means I need to generate load, which my server also has to handle.
     • The last thing I need to run is the demo itself. However, the charts are written in D3 and at the time were prone to jank, which is when the charts animate jerkily due to an overloaded CPU.
   • My poor 2012 Macbook CPU! I love it, but I do not trust it to handle all of those things at once while also driving a massive monitor and dealing with the “Other-People-Looking-At-Your-Screen Factor”. Fortunately, this not a situation any real user would find themselves in, but because of the constraints of demo-ing, we have ourselves a problem.
   • I ended up solving this problem by running the demo and recording the data passed from the database to the application. I just read it from disk instead of getting it from the DB. That way my server was left in peace to handle the other parts of the demo, and I didn’t have to worry about my load-generating Python scripts hogging my CPU.

2. Next up is the index build. I had to make sure that I had a large enough database that doing a search without an index would visibly slow things down. Caching can also complicate things. How to make our index build look consistently longer, but not too long?

   • Literally just add a sleep into the index build call. Sometimes the simplest solution is the best solution.

3. The last thing I’m going to talk about is finding my outlier.

   • The way that compass gets data for its schema charts is through $sample, which takes a statistical sample of the data and populates the schema charts with those documents.
   • If I want there to be one outlier, I can try modify my data so that it’s more likely to be picked up by the sample, but the clever thing to do would be to modify the $sample use so that I’m 100% guaranteed my outlier will be included.
   • How do I ensure that my sample picks up one outlier datapoint? Modify the code so that it does a sample, and then a query. Then it joins the two, and returns that information.

Conclusion

1. As a relatively beginner speaker I can’t say enough for carving out a comfortable space for yourself to grow as a programmer and a speaker. We don’t always get to jump in the shallow end first and I’m a huge proponent of fighting for the right to feel comfortable, no matter where you are or what you are doing.

2. There is a distinction between being misleading and ensuring that you have the space to show off the features that you are talking about.

3. Yes, giving talks is terrifying and there are tons of thing you can’t control. However, going through your demo and letting your mind run free with just how terrible things can get is:

   • First of all, a legitimately fun exercise that will probably improve your programming, or at least your test-writing skills.
   • A way to make yourself comfortable in a situation that you may find terrifying.
   • A great talk subject for when you’ve survived the experience. You then do more public speaking, get less and less afraid of it, and live happily ever after.

4. Thank you!

Requirements

This talk is for anyone, from complete beginners to experienced public speakers who feel their palms getting sweaty at the thought of doing a live demo. There is no technical knowledge assumed, just an interest in giving or hearing talks that involve real code being run. Attendees will leave with the feeling that they too can write and give a live demo that is completely bulletproof. I hope this talk will encourage people, regardless of experience, to fight to create environments where they can be successful.

Speaker bio

Anna Herlihy is a software engineer working for MongoDB in Stockholm. She is a contributor to MongoDB, PyMongo, Monary, and a few other MongoDB Drivers but is working now on Compass, the GUI for MongoDB. She enjoys hiking, road biking, climbing, and is most happy when she can do her work outdoors.