5 unexpected lessons from Pixar and Disney
Making a movie and creating software is more similar than you think
In Creativity Inc., Ed Catmull shares the amazing story of Pixar and the revival of Disney Animation. While a great story by itself, the huge surprise for me was its relevance to the software world!
Today, I’m going to cover 4 surprising lessons from the book:
You must throw away good work
The danger of falling in love with your work
Get out of your office to do research
You must feed the beast
You will throw away good work. It’s ok.
It was obvious to us that a large portion of our costs stemmed from the fact that we never seemed to stop tinkering with the scripts of our movies, even long after we started making them.
It didn’t take a genius to see that if we could only settle on the story early on, our movies would be much easier - and cheaper - to make. This then became our goal— to finalize the script before we started making the film.
“We had some people who had worked for a year on sets that were entirely thrown out,” Byron said. “Sometimes crews will ask us, ‘Why can’t you work all these problems out while you’re writing the script?’”
Finding Nemo seemed like the perfect project with which to test our new theory. As we gave the go-ahead, we were confident that locking in the story early would yield not just a phenomenal movie but a cost-efficient production.
Of course, it was not to be.
We ended up making as many adjustments during production as we had on any other film we had made.
Byron said. “The fact of the matter is that sometimes an outline sounds brilliant on paper, but when you see it up on the screen, with real voices, it is boring.”
Making the process better, easier, and cheaper is an important aspiration, something we continually work on—but it is not the goal. Making something great is the goal.
Imagine the frustration of creating a detailed set for a scene that is thrown out. A whole YEAR thrown out to the garbage.
Software developers often complain when the product managers / designers change the requirements in the middle of their work. “Why can’t they just come up with the correct requirements before we start working?” is a question I often hear.
In reality, a software application is like a movie. A Figma file might look brilliant, but when you actually play with the result, and see how it connects with the existing features, some changes need to be made.
Maybe the latency was not taken into account, so the information you worked hard to retrieve needs to be removed.
Maybe the new screen is overwhelming and whole components are deleted.
Or maybe the UX designer just had a better idea once she played with the result.
As long as people are doing their best to provide what they can on time - a change is a good thing. It’s ok to throw out your work - the goal is creating great software, not getting as much code to production as possible.
The danger of falling in love with your work
There is a phenomenon that producers at Pixar call “the beautifully shaded penny.”
It refers to the fact that artists who work on our films care so much about every detail that they will sometimes spend days or weeks crafting what Katherine Sarafian, a Pixar producer, calls “the equivalent of a penny on a nightstand that you’ll never see.”
Katherine, who was the production manager on Monsters, Inc., remembers one scene that perfectly illustrates the beautifully shaded penny idea.
It occurs when a bewildered Boo first arrives in Mike and Sulley’s apartment and begins, as toddlers do, to explore. As the monsters try to contain her, she wanders up to two towering piles of compact discs - more than ninety in all.
“Don’t touch those!” Mike screams as she grabs a CD case from the bottom, sending the piles crashing to the floor. “Aw, those were alphabetized,” Mike complains as she waddles away.
The moment is over in three seconds, and during it, only a few of the CD cases are at all visible. But for every one of those CDs, Pixar artists created not just a CD cover but a shader - a program that calculates how an object’s rendering changes as it moves.
“Can you see all the CD cases?” Sarafian says. “No. Was it fun to design them all? Yes. Maybe it was an in-joke, but there was someone on the crew who believed that each one of those was going to be seen close-up, and so they were lovingly crafted.” I don’t want to think about how many person-weeks this consumed.
There are software engineers who view their profession as art. They enjoy creating beautifully written code, 100% covered in complex Unit Tests, ready to work on a 100x scale, and taking care of any possible edge case.
The reality is that most code becomes dead code quite fast. Writing code just for the sake of creating a beautiful code base… Won’t get your company anywhere good.
Get out of your office to do research
When Pixar was prepping a movie about a Parisian rat who aspires to be a gourmet chef, several members of Ratatouille’s team went to France and spent two weeks dining in extraordinary, Michelin-starred restaurants, visiting their kitchens, and interviewing their chefs. They also trudged through the Paris sewers, where many a rat makes his home.
When it was decided that Carl Fredricksen’s balloon-propelled house would sail to the mountains of South America in Up, John sent a group of artists to see the tepuis in Venezuela up close.
These experiences are more than field trips or diversions. Because they take place early in the filmmaking process, they fuel the film’s development.
What feels daunting to the filmmakers when John sends them out on such trips is that they don’t yet know what they are looking for, so they’re not sure what they will gain. But think about it: You’ll never stumble upon the unexpected if you stick only to the familiar. In my experience, when people go out on research trips, they always come back changed.
It’s very rare that software engineers interact with customers, and I think it’s a shame. When you TRULY understand what your customers are going through, and what is their day-to-day, you’ll create much better software.
My business trips to the US were the most important weeks in my company, giving me tons of insights and food for thought.
For some ideas on how you can do that, check out my article “How can developers become business oriented”.
You must feed the beast
Software engineers are the biggest expense in most companies, and they hate to see them idle. That’s how we got to the feature-factory pattern - instead of focusing on validation and experimentation, companies focus on producing tons of features of dubious value.
Turns out it’s the same in movie-making:
Any company’s profit margin depends in large part on how effectively it uses its people:
The auto workers on the assembly line who are being paid whether the line is in motion or not
The lighting and shading experts who must wait for many others to complete their duties on a particular shot before they can begin to do their work.
[my addition] The software engineers who are paid a lot of money, no matter what happens with the software they write.
The solution, of course, is to feed the Beast, to occupy its time and attention, putting its talents to use. Even when you do that, though, the Beast cannot be sated. It is one of life’s cruel ironies that when it comes to feeding the Beast, success only creates more pressure to hurry up and succeed again.
Which is why at too many companies, the schedule (that is, the need for product) drives the output, not the strength of the ideas at the front end.
Despite good intentions, the result is troubling: Feeding the Beast becomes the central focus.
Thanks for sharing, Anton. I enjoyed learning about these connections.
Movie creators are happy that on-calls are not available to change a scene on-demand because it wasn't as funny as some expected 'did not work for the user'.
Very cool to learn about Pixar's process and how it relates to software engineering. I remember learning a bit about it in the book "How Big Things Get Done" with some overlap in the lessons