Friday, June 27, 2014

This Day in Pixar History: WALL•E Theatrical Release




6 years ago today on June 27, 2008, Pixar released their 9th feature film, WALL•E. A totally original film, WALL•E was a huge hit. It made over $223M domestically, making it the 5th highest grossing film of 2008 and the highest grossing animated film of the year, ahead of Kung Fu Panda, Madagascar: Escape 2 Africa and Dr. Seuss' Horton Hears a Who!. WALL•E is Pixar's 10th (out of 14) highest grossing film. It was also a critical success, garnering a 96% Rotten Tomatoes rating.

WALL•E was released with the short film Presto. Doug Sweetland made his directorial debut with the short film and to me is one of Pixar's most funny shorts.

WALL•E is one of those rare science-fiction films that is more than just amazing visuals. It has wonderful music (composed by Thomas Newman), characters we care about and an engaging story. From the 40 minute dialog-free opening to memorable scenes such as WALL•E looking over a hibernating EVE, the Define Dancing scene, and the emotional ending, it is easy to forget these characters are robots, and ranks as one of Pixar's finest films.

Some of you may not know that the origins of WALL•E began back in 1994, during a meeting at the Hidden City Cafe in Pt. Richmond, CA. WALL•E was the last film produced from the ideas that came out of that meeting, the others including A Bug's Life, Monsters, Inc. and Finding Nemo. Andrew Stanton talks about this meeting in the teaser trailer for WALL•E. Many Pixar fans, myself included, have made a trip to the Hidden City Cafe and had one of their great breakfast items like the Hidden City Scramble, or visited with owner Shellie Bourgault. Sadly the cafe closed in 2012 - I wrote about the closing which I discovered when I tried bringing my wife there while celebrating our 25th anniversary in the San Francisco area! Needless to say, my wife does not have the same, fond memories of the cafe as I do, especially when she discovered the reasons for the closing.


Sunday, June 22, 2014

Pixar In Concert

Photo from London program courtesy of my
friends Santi and Laura

There may not be a Pixar feature film this year, but for us fans there's always ways to get our Pixar fix, whether it be short films like Party Central, Car Toons episodes like The Radiator Springs 500½ or TV shows like Toy Story that Time Forgot. But for me, the most exciting Pixar-related event of 2014 is Pixar In Concert! Music from all 14 Pixar feature films and the 4 composers (Randy Newman, Thomas Newman, Michael Giacchino and Patrick Doyle) is performed by a symphony orchestra while scenes from the corresponding film are displayed on a large screen. These film scores and their composers have won 10 Grammys, 3 Academy Awards and have been nominated for an additional 10 Oscars.

For a long time, I didn't know if this concert series would come to Minnesota. It started with a few performances in California in the summer of 2012. Over time more performances, both domestic and international, were announced. Finally, performances in Minnesota were announced and I bought my tickets! My excitement only grew after my friends Santi and Laura from Spain attended a performance at London's Royal Albert Hall, and kindly sent me a copy of the program plus some other really great items like a copy of the program from the Pixar 25 Years of Animation exhibit that just closed in Madrid.

 Finally the day has arrived!! I attended the Pixar In Concert performance today at Orchestra Hall in Minneapolis, performed by the Minnesota Orchestra and conducted by Sarah Hicks (who also conducted the original performances at the Louise M. Davies Symphony Hall in San Francisco). Needless to say, the music was AMAZING! There is something special and extra-moving to hear music live, especially with a full orchestra. I think there must have been a lot of dust in the hall, I had tears in my eyes for most of the performance! I really loved all of it; I thought I could pick out a favorite piece but don't think I can. I can say I really, really enjoyed the pieces from Finding Nemo, Ratatouille, Up and The Incredibles. The pieces for Cars 2, Toy Story 3 and Brave were also wonderful. The last piece of music was from Monsters University, and the upbeat, high energy marching band music was an excellent way to end! They then did an encore performance of "You've Got a Friend in Me" to end the concert.

Yes, that's Pete Docter speaking. Sorry, it's an iPhone picture.

A huge surprise for me was that Pete Docter hosted the performances this weekend here in Minneapolis. Docter is originally from Bloomington, MN and is the creative director of the concert. Pete's parents were also in the audience, which made it even more special. Pete came out a few times during the performance to talk about the films and the music, and had some great stories to share. At one point while talking about The Incredibles and Cars 2, he actually made a FaceTime call to composer Michael Giacchino! Fortunately, Giacchino was at home "washing dishes" and "trying to keep the cat from eating the guinea pig", so he was able to share a couple of stories from both of those films (Giacchino said that during the scoring for Cars 2, director John Lasseter gave the guitarist a model of Finn McMissile and told him that he needed to become that character). I was touched that Pete made the trip to Minnesota, right in the middle of production of Inside Out. To me it's a testament of the importance of music to Pete.

If you're a fan of the music from Pixar's films, or just a fan of movie scores, I strongly recommend seeing this concert. Fortunately there are still quite a few performances scheduled, including ones in Seattle, Paris, Chicago and Denver. Plus, there will be 4 more performances held at the Davies Symphony Hall in San Francisco next month. And as a special treat, the July 17 performance will be hosted by Lee Unkrich, and John Lasseter will host the performance on July 18! There are still plenty of seats available for both of those shows. If you have attended, or are going to attend, a performance, I'd love to hear your thoughts on it - leave a comment below!


Saturday, June 21, 2014

Creativity Inc and Software Dev: Why We Iterate, Part 2: Evolve the Product

This is part 2 of my discussion on why using iterations are important to both Pixar making films and developers writing software. Part 1 covered the benefits of rapid feedback. In this post I'm going to focus on evolving the product. As a reminder, here are the quotes that inspired me for these 2 posts:
The plot would transform again and again over many months...
...we are true believers in the power of bracing, candid feedback and the iterative process—reworking, reworking, and reworking again...

(Excerpts From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 3, P. 85, Chapter 5, P. 127.)

It should be obvious, but I think many people miss the point of iterations. They are used to iterate the product, whether it is a film or software. By iterate, I mean to evolve and improve the product. How often have we heard Pixarians like John Lasseter, Andrew Stanton or Lee Unkrich talk about how they are continuously "plussing" or improving the film. The same goes for writing software, and was made clearer to me when I read a blog post on the Simple Programmer website. As discussed in this article, the point of iterations are to gradually improve the product, not introduce and fully complete functionality. Developing a product with iterations is not meant to be a linear process. That would be like the filmmakers at Pixar saying "OK, in this iteration we are going to work on scene X - write the script, storyboard, animate and finish the scene." But that's not iterating, that's just doing many small waterfall cycles. It's about the evolution of the product, making it better with each iteration.

I'll discuss iterations more in future posts, but in the meantime here's a great article regarding iterating not just the product but project teams as well.

Monday, June 16, 2014

Creativity Inc and Software Dev: Why We Iterate, Part 1: Rapid Feedback

In this post of my continuing series on comparing the principles Pixar uses to create films to developing software, we again meet one of the key concepts in Agile development - the iteration.
The plot would transform again and again over many months...
...we are true believers in the power of bracing, candid feedback and the iterative process—reworking, reworking, and reworking again...

(Excerpts From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 3, P. 85, Chapter 5, P. 127.)

I could talk a long time about iterations, but rather than one long and probably boring post, I will break it up into 2 shorter (but maybe still boring) posts. This first one will focus on the benefits of getting feedback early and often.

Pixar's process for developing films is very iterative. Their films don't get built in a linear "waterfall" fashion, going from writing to storyboarding to animating to lighting. Instead, it's an iterative, agile-like process (granted, their iterations are longer than the usual software sprint or iteration). Every few months, the filmmakers gather everyone at the company to view the film in its current state. Early on, the film is just in storyboard form with scratch voices and music. After eac screening, everyone is able to give notes - what's working, what's not, etc. As Ed says in the second quote above, candid and frequent feedback is critical to their process. The filmmakers take these notes and go back at it, re-working and re-boarding scenes, and slowly moving the film forward.

This is also the Agile way of building software. Rather than the traditional method of first gathering all requirements, then developing the software, then testing and finally releasing software, the system is described in stories (as described in earlier posts), and development starts almost immediately. The business owner or users decide which stories are of highest priority and the developers will work on them in an iteration usually lasting 1-3 weeks. By the end of the iteration, the stories will have been developed, tested and often times ready to be deployed. This process then repeats itself until all the stories are complete.

Why is an iterative approach a better methodology for both movies and software? In both cases, we want to get feedback early, while there's still time to make adjustments with minimal rework. When developing software, by involving the users or business owners early on, they can see and react to what we as developers are translating their requirements into. We may not have understood the user's desires or requirements. In addition, it's difficult to envision what an application is going to look like without something concrete to examine and try out. With an iterative approach and early feedback we can adjust what we're building while we have time and with less rewriting. Finally, by having the business owners involved every step of the way, they are able to pick the most important stories to be worked on each iteration, or even add new stories not envisioned when the project began. This helps us deliver a system that will meet their needs and one that adapts to the changing dynamics of the business.

Compare this with a traditional waterfall project where the users aren't able to see the final product until the end. At that point it's usually too late to make significant changes. And changes that would have been small had they been caught early become hard to implement because now their impact may ripple through much more of the system. This can lead to sub-optimal, quick fixes and technical debt.

Part 2 of this discussion on iterations will cover another benefit of iterations, which is evolving the product.

Saturday, May 10, 2014

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.

Thursday, May 1, 2014

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.

Sunday, April 27, 2014

Creativity Inc and Software Dev: Break Large Problems Into Small Ones

As I mentioned in a recent post, I've been reading Ed Catmull and Amy Wallace's new book Creativity, Inc. and continue to find many similarities between how Pixar develops films and how those techniques can be used to develop software in an Agile fashion. This is the first post to explore some of these similarities.

I'm going to start with the following quote, where Mr. Catmull is talking about coloring a bottle:
It was easier to figure out how to color and display each tiny piece
(Excerpt From: Ed Catmull with Amy Wallace. Creativity, Inc., Chapter 1, P. 37, iBooks.)

I like this quote being the source of my first post as this is a fundamental tenet of most Agile development methodologies. In traditional methodologies, the team starts with a requirements specification that can have hundreds or thousands of individual requirements. Trying to analyze a project with a large requirements specification can be overwhelming - it is easy to get lost in the details, and most times the details aren't necessary to come up with accurate estimates or the system design. On the other hand, breaking up a large project into small pieces of functionality (the Agile term for these pieces are stories) makes the project more manageable and easier to understand.

Let me give an example of using stories that ties back to the quote above. I don't know how well this is going to work, but let's just go with it. Assume you work for a company and you're asked to build a customer loyalty system, maybe to be more specific a new frequent flyer program for an airlines company. Just like the bottle in the quote above, thinking about this system as a whole could be overwhelming! Where do you start? What are the most important pieces of functionality? Somehow you need to break up the system in smaller components.

Using a traditional development methodology, you might have a requirements specification with thousands of requirements. This would be akin to shattering the bottle (OK, possibly over the top, but still, work with me) - sure, it might be easy to "color" each tiny little piece but you'll likely never be able to put all the pieces back together. You could also quickly lose sight of the bigger picture.

Instead, an Agile approach would be to define the system in small pieces, each piece representing a specific feature or function the system must perform, such as:
  • Users must be able to log in
  • Once logged in, users should be able to see their transaction history
  • Users should be able to shop for flights using their points/miles
  • Users should be able to request credit for missing miles
In this way, it is easier for all interested parties (business owners, project managers, developers, testers) to understand the system. We can also decide on the priority of each story/feature, providing flexibility in building the system. Writing stories is a difficult task but if done well it can be a very powerful and flexible mechanism.

This is just a quick summary of stories and a couple of their benefits. I'll talk a lot more about them in later posts.