Creativity Inc and Software Dev: Story is King

In this post of my continuing series on how the principles Pixar uses to develop films can be applied to building software, I am focusing on two quotes (hey, a 2-for-1!):

For all the care you put into artistry, visual polish frequently doesn't matter if you are getting the story right.

The first principle was "Story is King."

(Excerpt From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 2, P. 61, Chapter 4, P. 98.)

We've all heard John Lasseter and other Pixarians state "Story is King." A story at Pixar doesn't get green-lit until the plot is solid, containing the right amount of humor and emotion. Yes, the marketability of the film matters, but it is secondary to getting the story right. How many strands of Sulley's fur that were rendered or how realistic the lighting and reflections are in a scene won't matter if the story doesn't leave an impact.

After Toy Story was released, I was surprised when pundits and other movie studios started to proclaim that traditional 2D animated films were dead and that the future was CGI. So, because Toy Story was a hit and was computer generated, then to make an animated hit it was necessary to do it with CGI???? Wasn't it obvious that Toy Story and Pixar's other films have been successful because of the story?

In the same way, software can (and should) also tell a "story". The story for software is solving the needs of the users. As developers we need to work on that story, simplify it and build our software so the story makes sense for our users. How many websites or other apps have you used where it's obvious usability was not a critical element? I wonder how many developers and business owners use the applications they build?

I often think it's easy for developers, including myself, to get caught up in the latest technologies and wanting to use it in our projects. But we need to keep our focus on the story. Do these new technologies improve the usability or stability? Returning to the first quote above and flipping it, we can build the most stunning looking website with the latest toolkits, but if users find it hard to navigate our system, or if it's unreliable or slow, it won't matter.

We also need to consider the impact on maintenance and reliability of the technologies we are using. As a consultant, I'm usually only with my client for a short period of time. If I bring in technologies that the rest of the staff isn't familiar with, what will happen to the maintainability of the system after I'm gone? As a specific case, I'm building a system for my current client with Grails 2.3. The client has a number of applications at 2.1.5 but has just started using 2.3. I began with 2.3.5 but ran into some issues. We've been unsure of the exact cause of the issues (mostly dealing with continuous integration and deploying to Tomcat) so I upgraded to 2.3.7. Things have settled down but we're still struggling with a couple of issues. We've had a number of discussions, and given the client's expertise with Grails they are comfortable staying with 2.3.7, but it's important to keep the suitability of our tools and frameworks for a production environment in mind when determining which tools to utilize.