A Demo is a Performance

Writing software is like putting on a play.

Wait, what?! No it isn’t! Plays are for extroverts. Everyone knows developers are introverts.

Businesses don’t pay actors, they pay developers. And besides, Plays are a part of The Arts. Writing software is clearly a STEM field.

Ok ok ok, that’s not true either. There are plenty of extroverted developers. Software Developers can be any kind of person, even extroverts. You could see the world as a stage, and us as having our parts to play on that stage. So in that sense businesses pay for nothing but actors, some of whom have the role of software developer. And anyone who has read code from another developer that makes it easy to work with has benefitted from viewing code not only as STEM, but as communication. And communication is the heart of the Arts, whether it’s on the stage or in the repo. Each has its uses, but they all need a degree of art in order to be effective.

Here’s a first takeaway: Software developers and their teams can learn a lot from other disciplines. Case in point, The Theatre.

When I was an apprentice software engineer, a fellow in my cohort came to me. He was having trouble with his end-of-sprint IPMs (Iteration Planning Meetings): his demos were terrible. In an agile workflow, a developer (or team of developers) will work in timeboxed iterative development cycles called sprints. These are typically one or two weeks long. At the end of this sprint, a series of rituals are conducted to acknowledge what was done this sprint, what needs to be done next sprint, and any improvements the team would like to try. Many of these rituals include the team’s non-technical stakeholders, so that they can give feedback, provide context, and set the next sprint’s priorities. The demo is the first part of that IPM where working software (every new feature completed from the beginning of the sprint) is presented. My fellow apprentice’s stakeholders were unhappy with his demonstrations, and had mentioned mine as a better example. So he came to ask me why my demos were noteworthy. He already knew I had a background in theatre. Without even thinking I said to him, “Well, a demo is a performance.” He suddenly understood.

Writing software is still writing. Writing is an art and presenting that writing in front of an audience (theatre) is yet another art, which is why the demo at the end of a sprint is a performance, and by necessity must be a performance. Even if we decide that from the point of view of our math-and-science profession that it hurts our image (and possibly our paychecks) to start considering software an art, ignoring the fact that the demonstration is a performance will not alter the need for your software, and you to perform. You’ll simply put on a poor demo, one your clients or stakeholders will dread. If they dread watching the result of your work, they’ll dread you too. And that creates a host of problems. Good demonstrations, ones where you take its performance aspect as a necessity, will have the opposite effect. They’ll bring delight, spark productive conversation, and build trust. Part of your job as a software engineer is to put on a show. Ignore the performance at your peril. This is one thing the theatre can teach software developers.

A Sprint is a Rehearsal;
A Demo is a Performance

Let’s unpack that metaphor to see the details of its implications.

Presentation “What makes a great painting is its frame.”

If a Demo is a performance, it means that the stakeholders are an audience. I don’t know if you’ve ever been to a play. Many have, but many haven’t, its got a different vibe than a movie. There is, of course, a snack bar. At nicer theatres, it includes wine, beer, and mixed drinks or cocktails. Many times there are ushers who will escort you to your seat. The play’s presentation is not limited to the set on the stage. The house itself is decorated in an eye-catching fashion. The seats are arranged so that any audience member can see they are part of a larger community of people coming to see the performance. There are box seats for prominent celebrities of this community (most likely a known member of the aristocracy, government, or business community). These box seats are positioned about halfway up the wall next to the stage in a way so the rest of the audience can watch the celebrities watching the play too. It’s no accident that box seats are where they are. Think of it as pre-social-media celebrity reaction videos. Mind you, those box seats have a rotten viewing angle for the celebrity, but then again the primary reason to take a box seat is to be seen. Being able to watch the play is secondary. My point is, that the experience of a play starts way before the play even begins. It starts when the audience enters the building. Even before that, as audience members drive up and are escorted from their cars. Even in a small experimental “black box” theatre, walking into the space and seeing the set, the lights, the spartan intimate setting of thirty seats or so is a critical part of the performance. As Steve Martin wrote (and most likely stole, as any good artist does) in his play “Picasso at the Lapin Agile”, What makes a great painting is its frame.

Translating this to a technical demonstration: Maybe it’s not a fancy gala, but be deliberate about what you’re going to wear. Maybe wine and cocktails are inappropriate, but consider a basket of snacks in easy reach. Bonus points if you find out what the stakeholder’s favorite treats are before the demo and order those. Consider where your stakeholders will sit, and the kind of chairs available. Consider the decorations and ambience of the room, and what that is saying about the work you’re going to present. Where in the room will the presentation take place? Where will you present from? How will your stakeholders enter and leave the space?

If the demo is happening over video conference, that makes it all the harder. Consider the camera angle, what of your background is exposed, or what virtual background you pick. Subtle down-angles make you look submissive and a touch out of control. Subtle up-angles will make you appear arrogant and looking your nose down on your stakeholders. An even angle will make you seem on-the-level. Consider your lighting. face a window as an easy cheat to get natural light on your face rather than being shadowy and back-lit. Maybe even get a ring light or set up 3-point lighting. Consider what your stakeholders will walk into when they join the meeting. A black screen? The deployment dashboard? A video of a waterfall? A poster with a photo of an eagle and the word “excellence”? A lively conversation you and the other devs are having? I’m not saying any of those are great choices. Depending on the client, depending on you, some of those are terrible choices. But first impressions matter, even the hundredth time. Make a choice about it.

Know your Audience

Its one thing to grasp the choices you can make to present the demo, a demo a la Cirque du Soleil would certainly be impressive. But to be effective, you have to keep the stakeholders in mind to know what choices you should make. Learn what will make your stakeholders feel comfortable. Some stakeholders will not feel comfortable with a level-angle and a well-dressed, well-lit background. Others will be really pleased by that same setup. If in doubt, observe how your stakeholder is set up in the call as a starting place for how you should present your own video. In a co-located environment, it’s easier to subtly observe your stakeholders’ preferences, behaviors, mannerisms, attitudes, and make choices that will support and (once there’s a great deal of trust) lightly challenge those attitudes. What you choose should be based on what you learn about yourself, your team, and your stakeholders.

TLDR; Be intentional and specific about every detail of the demo.

In software apps, oftentimes we accept a bunch of ‘sensible’ configuration defaults in order to get something quickly up and running. That’s the opposite of what you want to do for a performance. ‘Accepting the defaults’ in a performance is called ‘cliché’ and the best you’ll get from leaving unexamined clichés in your performance is grudging tolerance. Your audience won’t be able to articulate why they are underwhelmed, but they’ll feel you’ve cut a mental corner with them, and they’ll feel the disrespect that implies.

However, even though you should never blindly accept the default, there are times when the default really is the best choice. In that case, consciously use the default. You’ll know you’re in the clear if you can discuss the reason why you chose the ’typical’ way. Besides, once you’ve chosen the default for specific reasons, it is no longer default. Now it’s specific. Your audience won’t be able to say why, but they’ll feel the difference and like it.

Otherwise make your choices based on what you learn about the stakeholders and what you know about your own personality. This will require work, both self-reflection and getting to know your stakeholders.

Preparation

In-person or remote, you’ll want to give yourself the time to prepare for the demo. Plan out what the order of events will be. Test the equipment (projectors, internet connection, servers, etc) to verify they work the way you intend. Perhaps rehearse certain key speeches. And also make sure the seats, and environment are arranged the way you intend them to be experienced. When the demo starts, you’ll need to improvise some, but the preparation will make that easier, and will make the entire experience smoother. Stakeholders will feel respected if you took the time to make sure they didn’t have to watch you fiddle with an HDMI cable. At first, you might need an hour or two to prepare. As you become a pro at it, and as you get to know your stakeholders well, you might pair the prep time down to 30 minutes. Plan this time into your schedule. It’s important. As an engineer your job is not just to write code, but to communicate to your team and to those non-technical folks who are paying for your services.

They may not be able to articulate why, but watching a demo that is well-prepared will feel better to your stakeholders. One that has no preparation, or no thought behind the presentation will feel off to them. They won’t have the words to say why it’s off. They just won’t like it as much.

The Performance

Being good at public speaking takes years of practice, and there are numerous techniques and approaches, but here’s a simple one my voice teacher, Steve Satta-Fleming taught me:

1. Breath
2. Connect
3. Speak the Truth

Your voice may shake. Let it. That’s the truth. Over time your voice may shake less. No one who presents ever feels great about it, even the most accomplished actor or public speaker. Those nerves are a part of life. Take the time to breathe. It may sound dumb, but you can forget to breathe when you’re presenting and not even realize you’re doing it.Breathe. Also take the time to connect. It can be scary, but make some kind of socially or culturally appropriate connection with your audience, that maybe a joke, it may be eye contact, it may be a well-executed bow, but you need to give the audience something to let them know that you’re with them and they’re in good hands. Then focus, and present what you’ve prepared. Take your time! Clock time on the stage is about 5x the speed the audience feels. You can afford to go even slower.

Afterward

Set asside a few minutes after the stakeholders leave to go over how they took the demo, and what you can do for the next demo to make it more effective. It is a great way to continuously improve. Even if demos are awkward at first, using this technique will make sure your skills get better. It also gives you a chance to adjust to the stakeholer’s changing attitudes. Consider this a short informal kind of ‘retrospective’. Retrospectives are typically hour-long or 90 minute agile team meetings where everyone in the team goes over what went well and what can be improved in the course of a sprint. All participants have an equal voice, and no one is blamed for poor work. Rather, the focus is on how to improve the techniques the team uses to prevent poor work, and enhance what’s working well. A very short informal version of this retrospective can be used in the few minutes after the stakeholders have left. This is an opportunity to improve the demo and better focus the presentation on what the stakeholders will enjoy.

What it all means

The frame, and your preparation of that frame tells your stakeholders what to anticipate.
If the stakeholders anticipate something great, they’ll view what you present with that bias.
If they anticipate something bad because you got the framing wrong or ignored it entirely, the greatest breakthrough in the world will not be enough for them.

If, on the other hand, all this sounds like it’s too much for you, it’s because these are details and considerations most engineers don’t get into in their day-to-day work. It’s as natural to be overwhelmed by this info as a theatre professional might be at hearing about the MVC pattern used for their online box office. But that doesn’t mean it’s not important to spend the mental energy required to learn it. (I have even recommended theatre professionals learn something about software engineering for the same reason).

I’ve met very few engineers in my time that were honestly giving less than 110%. Wouldn’t it be nice if your stakeholders saw that effort and respected it? Wouldn’t the improved relationship be worth spending the time to help them appreciate the work you do? Those things are not just possible, it’s what your stakeholders want to feel. Performing your demo is an important lever to get you and your stakeholders the working relationship you all ought to have. Give it a try. No one gets it 100% right, especially not the first attempt, but as you do it, you’ll understand more and more. Before long, it’ll be as natural as all the other complex thought work you’ve learned to do.

Extending the analogy

I’ve mentioned that if the demo is a performance, then the sprint is the rehearsal for that performance. It could be helpful to think of the work you do each iteration as driving towards being able to present that work to stakeholders. In that case, increasing feedback cycles using fast unit tests, pair programming, and test-driven development aid the “rehearsal”, but the usefulness of the analogy stops there. In a play, what matters is the presentation. The set doesn’t have to be crafted flawlessly with a modular design that separates concerns and allows on-the-fly adjustments. It just needs to be safe and serve the story. Writing solidly built software requires more invisible work than what would be necessary for a show. You might also consider the demo as an intermediary performance, like an audition with just the producers in the room. In that case:

Sprints are Rehearsals
Demos are the Auditions
Production; the Show

But you can take any analogy too far. There are limits to what’s useful to software engineering from other disciplines. Case in point, Dance. As an apprentice, one time in my Daily Standup, I did an interpretive dance to represent the current state of a Java HTTP server I was writing. Yeah, no one understood me that day.