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.

Creativity Inc and Software Dev: Solve Problems for a Reason

For my second post in this series on how the principles in Ed Catmull's new book Creativity, Inc. can be applied to software development, I wanted to look at this quote:

...we felt like we were solving problems for a reason.

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

The MSC CM-5

During most of the 1990s I worked in research positions. I was first at the Minnesota Supercomputer Center (MSC) working with massively parallel supercomputers. Do you remember the supercomputer in Jurassic Park? That was a Thinking Machines CM-5, which could be configured with up to 1024 SPARC RISC processors, each connected to 4 custom floating point processors. MSC received serial number 1 of the CM-5 in 1991, and I was the system administrator of that machine. I then worked at U S WEST in one of their advanced technology labs, researching ways to manage Frame Relay and ATM network switches. I had so much fun working at these places. We were on the bleeding edge, doing things that hadn't been done before, going to technical conferences and giving presentations. I learned a lot about teamwork and perseverance (such as working over 30 hours straight debugging and modifying the running OS kernel of a multiprocessor Sun 4/690).

But in the late 1990s I realized I wanted a change. Much of my work had been on things that didn't have an immediate impact on the business. I wanted what is in the quote above - to solve problems for a reason. So when I received an offer to lead a new group building the next generation of network management systems I jumped at the opportunity. That is where I began building enterprise systems and set in motion opportunities for the next decade. It was also when I realized I wanted to build software in a more agile fashion, although at that time I didn't know it by that name.

When working for my company or client, I want to write software for a reason, that I know will make an impact. I've worked on projects where we spent days working on functionality that we knew would get very little use, but it was in the approved requirements document so we had to do it. This is a guaranteed way to lower team morale and lead to apathy.

In my first post I introduced the Agile concept of a story, a short description of a piece of functionality, usually written from the user's perspective. By having a backlog of stories and working in an iterative fashion (which will be explored in later posts), the business can choose which stories are of most importance at that moment. In such an environment, we can be responsive to the changing needs of the business, and will feel more confident that we are solving problems for a reason.