Creating a Software Application is Like Creating a Theatre Production

As a person who is new to coding, I like to try to find parallels for things that are more familiar to me. Since I am a trained actor, I often view creating an application for a client as similar to putting on a theater production for an audience.

Some of my Revelry software engineering colleagues have years of experience or a computer science degree, but many of us don’t. I got into it from a different background. I grew up in Gretna, went to college at LSU, and majored in theater with a minor in psychology. After working in the service industry for several years, I slowly became interested in tech. Coding seemed like a perfect mashup of math, logic, analytics, and languages.  After five months at the Flatiron School boot camp, I started my first software engineering job at Revelry just over a year ago.

In this article, I will explain the ways that I understand the software development process, as viewed through the lens of theatre. I hope that this can help experienced engineers view the process in another way. I also hope this inspires people with non-traditional backgrounds to feel like they can enter into tech as I did.

The product audience

Everything we do, in software development for partners and in theatre for companies, is driven by a goal of connecting with real people. Whether we want a sold out audience to give a standing ovation or to increase downloads in the App Store, I keep the human experience in mind.

Directed by the product owner

So in my brain, the product owners operate as the directors. It’s their vision. It’s their show or product that they’re trying to create. Ultimately, they have the final say in what’s going to happen and how it’s going to happen. While creating a product is a collaborative effort, the product owner is the director of the show.

Designers are… designers

Designers work much in the same way in both fields. They are in charge of creating the artistic form and function that provides the customer with a wonderful user experience. Theatre requires multiple types of design: set, sound, costume, lighting, and more. Similarly, software also requires varying forms of design: UX, UI, branding, illustration, front-end, graphic, motion, and more others. Without great design and communication between teams, our product cannot engage users just as an audience might find it difficult to grasp the story within a play.

Researching and dramaturgy

Dramaturges, to me, are the very unsung heroes of theater. Most people don’t even know that term or know what they are, but they’re so important for providing relevant information for a product. A dramaturg’s job is to research and provide context that can be incorporated into the production or program to give context and accuracy to the audience and viewers. For instance, if you were to perform a historical piece of a given, specific time period, a dramaturg would be responsible for providing historical background, politics of the time, common architecture, dialects, fashion, and whatever else that may be relevant to a given production.

Designers and product managers can take on that role in the tech world as well. We need to know our target audience, the history of the context of the product in the market, research best practices into why and how things should look, and ensure that we are incorporating other needed information from other disciplines.

Product managing as stage managing

To me, the parallel that stands out the most is that of the product manager as the stage manager. They both are the hub of communication. If you’re going to be late for a meeting, the stage manager or product manager is the person that you should go to. They can keep everyone else informed, rearrange times for meetings, and make sure that everything remains on track.

If the product owner, designer, and engineer can’t agree, the product manager sets timelines and keeps us all on track. If we forget our lines or miss a crucial piece of the product roadmap, they are there to make sure the roadmap is followed. If we aren’t standing in the right place on the stage or forget to get approval on a step, they are there to make sure we don’t get crushed by an incoming set piece or make sure nothing is broken in production.

Plays and roadmaps

Just as a production relies on a script, we rely on a product roadmap to guide our development work. Sometimes we might be given a roadmap by a company we work with, the way that a playwright writes a play. But much like in theatre where roadmaps are sometimes altered to fit specific needs that arise during the rehearsal process, software engineers need to learn how to adapt to unforeseen circumstances and to try different tactics of achieving the same end goal.

Engineers on the stage

Maybe it’s because I am an actor, but I view the engineers as the people on the stage during the performance: the actors AND the tech crew. We take everything that the product owners, designers, and product managers have given us, and we put them all together in moving pieces that come to life in front of an audience.

A product owner will tell me, “I want to create this beautiful product. Here’s my goal. Here’s what it’s supposed to accomplish. Here’s what I want it to do.” And then the designers will come in and say, “Okay, that’s great. Here’s what I think it should look like. Here’s where these buttons should be. Here’s what the user experience should be like.” And then I think, I’ve read my script. I’ve learned my lines. Now, let’s get into rehearsal, let’s do a show and put it there on the stage. The stage is, in this case, your computer, phone, or anywhere else the software is being used.

Just as actors and stagehands rehearse their performances before opening night, we must run dozens of tests before deploying anything to a live site. It takes a lot of testing and trial runs before releasing a product into the world.

Rely on your ensemble

It’s important to remember that you’re not on your own. Just like when you’re doing a play, it’s never one person. It takes the village, and everybody has to be there for each other. I rely on my coach, my team, and the process to create a product.

Extending the metaphor

This synopsis provides an overview of how I think about the roles I regularly work with in my day-to-day life, but there are multiple ways to extend this theatre metaphor into other aspects of product development. The box office is the sales team. Theatre critics are the QA team. Understudies are apprentices. And how do choreographers, orchestra musicians, make-up artists, and more fit in? I invite you to consider ways to extend this metaphor in ways that make sense to you.

Both of these fields can feel very intimidating, and imposter syndrome is very real. So start with relating things to the work you do know to feel more comfortable. It’s okay that you don’t know everything. But you do know something. So find that piece of your experience that is applicable, and use it to learn more. I wish you well on your journey. Break a leg!