This chapter is from the book

Although presentations frequently include demonstrations, presentations and demonstrations are not the same thing. A demonstration is designed to show directly how something—generally either a tool or a technique—works. A presentation presents information about something; the something could be a tool or technique that you discuss with or without demonstrating it. The patterns and anti-patterns in this chapter clarify this subtle but important (and often missed) distinction.

It is common to build a presentation around the output of a tool such as spreadsheet software or a programmer’s integrated development environment. Although you can embed the output directly into the presentation, we show several better patterns (Traveling Highlights, Crawling Code, and Emergence) that add veracity and remove risk.

Project Manager Pam’s Perfectly Putrid Performance

Pam’s team has been working like mad for the last three weeks, realizing the new client vision for one of its software products with blood, sweat, tears, pizza, and overtime. The team has performed beyond its potential and hit the deadline. All that’s left is the showcase, where Pam will demonstrate all the new killer features. The client knows this is brand-new code and might have a few bugs, but the new functionality is vital to the vision for the product. Unfortunately, along with Pam’s team, Murphy (and his law) showed up for the showcase. Even though the new features worked brilliantly over and over when Pam practiced them, the showcase was a disaster. Pam didn’t get a chance to show the new business vision because the bugs (which would have been gone by the following week) sabotaged her.

Pam didn’t yet understand the distinction between a presentation and a demonstration and inadvertently ended up implementing the Dead Demo antipattern. She wanted to present the new features to get approval, but she ended up demonstrating bugs and imperfections. She thought she wanted to demo the new product, but it was not ready yet: she would have been better off building a presentation and using a pattern like Lipsync, which would meet her goals exactly.

Shoeless Subramaniam’s Spectacular Show

Venkat Subramaniam, a well-known speaker on the software-developer conference circuit, is famous for his talks’ style as much as their content. He talks about highly complex subjects, yet the closest thing to presentation software he uses is a text editor, which holds his agenda. He dazzles the audience by typing code and explaining as he goes, incrementally building software and running it periodically. To the outside observer, this is the most obscure entertainment imaginable: 100 people with their eyes glued on a screen with scrolling text, having the time of their lives, entranced.

Subramaniam has been doing this for years because he has mastered the skill of talking and typing at the same time, and he has the concentration ability to hold that complex context for hours at a time. In a talk Neal attended that involved an incredibly complex tool and many multilevel steps, Subramaniam built an impressive artifact in about 45 minutes, explaining what he was doing and why. A few unexpected things happened along the way, but he handled them adroitly, explaining what had happened and how to solve that type of problem. When he was done and showed the finished artifact, the audience gave him a standing ovation. His performance was a tour de force of concentration and skill. Like a professional athlete, he makes the difficult appear easy.

Oh, and he always takes his shoes off before his talks. That helps him to relax—and is the inspiration for the Shoeless pattern.

Tester Tom’s Tragic Hotel Wi-Fi Trust

Tom is an adrenaline junkie. He doesn’t jump off skyscrapers or hurtle down a frozen luge track on ice skates. No, Tom likes to give presentations that require an Internet connection. In fact, he’s infamous for copying a URL from his slide deck, pasting it into a browser, and then waiting for the page to load. This task is usually accompanied by a series of apologies and curses. Nothing drives an audience to their smartphones faster than watching a web page fail to load. Tom is convinced the attendees won’t believe something is real unless he actually demos it live. That might be the case in certain circumstances, but a shred of doubt is better than the annoyance of watching a status bar.

Despite what you may think, some hotels (and conference centers) actually don’t have Internet connections at all! Tom learned this the hard way after flying halfway around the world. As you can guess, his talks required an Internet connection. He’d given the talks successfully many times in a variety of venues, and he’d grown complacent. The night before his presentation, he was told that the conference center did not have an Internet connection. Tom worked through the night implementing an emergency Lipsync pattern, recording his demos via hotel Wi-Fi. Needless to say, he hit the espresso hard the next day.

Hotel (and conference center) Wi-Fi is completely untrustworthy. Someday we’ll live in a world with ubiquitous high-speed Internet connectivity, but until then, just assume you won’t have a Wi-Fi connection. Even if you do, the odds that it’ll function at a level necessary for your talk are not good.

Pattern: Live Demo

Also Known As

Live Tool Use, Live Coding

Definition

You demonstrate in real time how something works or how to do something as part of your presentation. Successful implementation of this pattern can turn a demonstration into performance art.

Motivation

The motivation for demonstrating something within a presentation varies widely. At its most noble, it shows the audience members something they want to know in an interesting, entertaining context. Perhaps it seems like less work to throw together a few Bullet-Riddled Corpse introduction slides and then demonstrate the tool or technique in an ad hoc way. At its worst, it boosts the presenter’s ego while lacking information quality and density. We identify this as a dangerous pattern to be used by advanced presenters only. We’ve seen many presenters who think they are delivering a great demonstration but are actually just annoyingly stroking their own egos.

Live Demo can be a life saver if you don’t have enough material to make a compelling presentation in the time you have. Interacting with a tool is a great time sink and—if done to encourage audience interactivity—a benefit to the audience as well. (But see the Dead Demo antipattern for the dark side of this motivation.)

Applicability/Consequences

Live Demo works particularly well when the following occurs:

The presentation consists of instructional material about a tool or technique.

The topic is completely new to the audience, and you want to start from a known context to lead them toward new ideas.

The focus of the talk is the interaction with the tool or application of the technique.

The technique is something the attendee is expected to mimic, in whole or in part, either in real time or later.

This is an effective pattern when the focus of the demonstration is a tool or technique. It becomes the Dead Demo antipattern when that’s not the case. It’s extremely difficult to perform well—and trivially easy to do so poorly that the audience checks out completely. Performing a Live Demo well takes an enormous amount of practice (see Carnegie Hall pattern), deep knowledge of the subject, bravery, and calm in the face of the unexpected—along with the ability to speak in well-considered, articulate sentences while performing a complex and error-prone task in front of a large group of people. You might want to consider the Lipsync pattern instead.

When performing some intricate technical feat such as writing source code, you’ll make mistakes, no matter how well you’ve practiced. One of the benefits of live demonstrations is the contextualization for the audience members: they empathize when something goes wrong. It makes the presenter more human and provides the opportunity to discuss important tangents. However, the worst part of this pattern also manifests in this situation: it can destroy or at least seriously harm the presenter’s reputation if an unrecoverable error or mistake occurs.

Mechanics

You must be effective in ad-libbing with the tool you are demonstrating (with). The most difficult aspect of this pattern is the immense level of audience concentration the presenter must maintain. It’s boring to watch someone use a tool and excruciating to watch someone backspace over mistakes repeatedly, so most presenters keep lively banter going at the same time. That’s hard enough to do when things go well and extremely difficult when unexpected variations arise.

Make sure you have a firm agenda. It’s OK to stray from it at the audience’s request, which is one of the benefits of this approach, but you don’t want to be seen as fumbling around. Make sure you have goals in mind and keep on track. Be willing to say no to audience requests if you think they’ll provide a poor Live Demo experience.

Practice is essential. By demonstrating something in front of a group, you are an expert on it, no matter how much you might disclaim otherwise (which never helps—see the Going Meta antipattern). You must look polished in your demonstration and should be able to answer questions as you go. Your knowledge must significantly exceed that of others in the room so that you can answer questions gracefully.

One way to reduce risk if you do undertake a Live Demo is to create intermediate versions or snapshots beforehand of what you’ll be demonstrating live. If something goes terribly wrong, you have a known good place to restart and hopefully regain your composure.

If you do want to show the audience the mechanics of something via a Live Demo yet don’t want to incur the ongoing risks, you can start the presentation with a few Live Demo examples then switch to a safer pattern like Lipsync.

Known Uses

Nikon, on the release of its D4 DSLR camera, had a situation in which it was imperative to give a live demo.1 To prove that an innovative remote-control feature was already in the camera hardware (not an implementation of the Lipsync pattern), the presenter turned the camera on the audience members and displayed live pictures of them. The presentation gave credibility to the feature and assuaged any of the audience’s concerns that it was technological vaporware.

In 1994, Bill Gates decided to do a live demo of Windows 95 and its Plug and Play capabilities. He performed a move that had likely been practiced dozens of time—connecting a scanner—and snap, the dreaded “blue screen of death” appeared.2 Gates tried to deal with the situation as well as possible, but the audience lost its focus on the talk’s real goals and laughed hysterically. The snafu made the news on many local TV stations around the world—not exactly what Gates was hoping for.

Related Patterns

The Dead Demo antipattern is the evil twin of Live Demo.

The Lipsync pattern is a common way to replace a Dead Demo with a presentation.

Developer Dave’s Dazzling Code Show

Developer Dave worked on his killer demonstration for the Lunch-and-Learn all month. He found some awesome examples of the new web framework and built a significant piece of the current system in very short order using this new technology. As the meeting approached, he honed his examples to a fine edge.

But Dave didn’t count on the meeting taking place in the black hole meeting room, where you can never get a good Internet connection via the wireless network. During the demo, Dave realized with growing distress that none of his examples work without Internet access. What should have been a fantastic victory—convincing everyone that he has the found the correct tool to solve all their problems—instead left everyone with a sour impression, both of Dave (for wasting their lunch break) and of the demonstrated technology, which doesn’t seem to do much.

Murphy (of the eponymous law) always shows up at important meetings, even though he’s never on the invitation list.