Building Software Is Like… Producing a Movie?

I just saw a great Twitter thread by Phil Lord, one of the writers of The Lego Movie and Spider-Man: Into the Spider-Verse. I’ve written before about parallels between software and TV/movie production, and the analogy continues to be relevant. There are a few lessons from Phil that can definitely apply to software.

1. No matter how clear your initial vision, things will change.

Spider-Man: Into the Spider-Verse is, in a sense, a well-understood business domain. That’s a weird way to put it, but there’s existing content for the Miles Morales Spider-Man, and Brian Michael Bendis (Miles Morales’ co-creator) consulted on the script. “Subject matter experts” were available to help.

Before even starting the film, they knew the character, his backstory, and his motivations. There was something to build on. Phil Lord wrote the script before production began.

And yet, Phil says in the Twitter thread that they “did a big shakeup of the story less than a year from release.”

This mirrors every software project I’ve ever been on. We start with planning and research, we consult with domain experts, we define a direction for our next release and build a backlog. But as we move, things change. We experience the in-progress product and decide to change things, or it turns out our partners can’t provide the service we were expecting, or there is some other change.

2. Continuity is hard.

Phil alludes to having already animated some sequences before his story shakeup and needing to figure out how to reshape the story without wasting that existing work. With TV and movies, continuity is easy to see: if a character is wearing a hat in one scene, it can’t just disappear off of the top of his head at the next cut.

Continuity in software is just as important, perhaps more so — a moviegoer might not notice every detail, but the computer assuredly will. With software, continuity means consistently enforcing rules. For example, if I don’t have permission to edit a document loaded from my dashboard, I shouldn’t be able to edit it if I got there through my bookmarks instead.

Unfortunately, not all software rules are visible, making it very hard to check continuity.

3. Low fidelity tools are valuable.

Phil managed his team’s changes with whiteboards and sticky notes.

That’s exactly the same toolset I use to manage scope and priorities. Lo-fi tools like whiteboards and sticky notes make things easy and cheap to change. There’s often pressure to go electronic or use higher fidelity tools, but everybody knows how to use a sticky note, and they won’t need a license or login.

4. Use your own language.

Phil describes one of the whiteboard pictures this way: “It’s less of an outline and more of a triage docket of what we were going to do to each sequence. It made sense basically to no one but us.” And that’s perfectly okay.

All of your scribbles, diagrams, and sticky-notes are meant for you, not the end-user. Everything that’s not the final product is for you, and you’re the only one that needs to understand it. Embrace language (both verbal and visual) that helps your team manage the complexity of the project.

Apps are movies, not bridges.

I’ve heard many people lament, “Why can’t software be as reliable as bridges are?” Leaving aside the spotty history of bridge reliability, I think software is much more fairly compared to television and movies. The script can’t tell you what it’s going to cost to film, and the pitch meeting isn’t the same as watching the movie.

All of these sorts of large projects involve uncertainty, and I think we can each learn from the experiences of others in parallel industries.