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.