Earlier this year, Emma Coates, Pixar’s Story Artist, individually tweeted twenty two guidelines for story writers. While the list is expertly geared towards traditional storytelling, its insights are applicable to just about any profession. After all, every product has to tell a story to its customer.
With that in mind, here is how (half of) Pixar’s 22 Rules of Storytelling can be applied to software development.
2. You gotta keep in mind what’s interesting to you as an audience, not what’s fun to do as a writer. They can be very different.
Many software projects have gone off the deep end, because their developers spent too much time adding features instead of solving problems. Stay focused on the core purpose of the software. Quickly vet and act upon customer feedback.
4. Once upon a time there was ____. Every day, ____. One day ____. Because of that, ____. Because of that, ____. Until finally ____.
Most computer users don’t see software as developers do, as streams of logic weaved together to process data. They see programs as something more ethereal and anamorphic. Their journey to complete a task is more analog than digital, and the best programs guide the user through the multiple tribulations of that path.
5. Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff, but it sets you free.
What gets the user from A to B with the least amount of effort? Would sacrificing functionality, used a small fraction of the time, make it easier to perform a common task?
8. Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time.
Every software developer has sat on a product for much longer than he should have, fine tuning it into oblivion. Release a product as soon as its market worthy and add fixes and new functionality afterwards.
10. Pull apart the stories you like. What you like in them is a part of you; you’ve got to recognize it before you can use it.
It never hurts to straight copy design and features of programs you enjoy using. You can always circle back, before release, and fine tune them to make them your own.
11. Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone.
Software is built on code, not concepts. Building out your program will reveal many more flaws in your plan than hypothesizing will. Even if you wind up scrapping the whole thing, you’ll wind up with new ideas and lessons learned.
13. Give your characters opinions. Passive/malleable might seem likable to you as you write, but it’s poison to the audience.
Give your programs character through user interface and user experience design. Make a statement. The more passive a developer is with these decisions, the more a product feels like boring, enterprise software.
14. Why must you tell THIS story? What’s the belief burning within you that your story feeds off of? That’s the heart of it.
If you don’t care about the problem you’re solving, find another one. There will be so many low points in your journey that the only thing you’ll have to feed off of is a preternatural desire to see a successful end result. Like Mark Cuban said, “if you have an exit strategy, it’s not an obsession.”
17. No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later.
Everything in software development is a lesson to be reused later. What seems like dead end code now may be a set of functions or classes that can be repurposed in other feature sets or entirely different programs.
20. Exercise: take the building blocks of a movie you dislike. How d’you rearrange them into what you DO like?
The beauty of software development is that this isn’t just an exercise – it’s one of the best ways to discover viable business models. Investigate an underserved, niche market and you’ll almost always find software companies resting on their laurels and charging high prices, due to their lack of competition. Taking advantage of such situations can be very lucrative.
22. What’s the essence of your story? Most economical telling of it? If you know that you can build out from there.
Simplicity is the key to successful software. Refine the program down to where it takes no more than a couple clicks (or touches) to complete any given task, regardless of how much work the back-end is doing.
