Business-focused custom software

Go Back

Software project lessons from 2001: A Space Odyssey (and 2010)

HAL "It can only be attributable to human error." --HAL, in 2001: A Space Odyssey

Sweet, lovable HAL. It is hard not to love HAL with his serene voice and impeccable logic. Still, when he became homicidal we were all glad we weren't stuck on a spaceship with him. But after seeing the movie recently it occurred to me that there are a number of lessons we can learn from HAL and his two movies that apply to software development projects.

Conflicting objectives are bad. Very bad.

HAL's fellow Discovery crew mates found out the hard way that conflicting objectives can be dangerous. We learned in 2010 that HAL starting killing the crew because he was given conflicting mission goals and this caused him to become paranoid. But hey, that mistake probably only happened because of government secrecy, right? That wouldn't happen on a typical business project, would it?

Unfortunately, yes it would and does. Before you start any software project, make sure the objectives are clearly defined, and revisit them periodically to make sure they haven't morphed into something else.

You have to trust your team.

The movie 2010 explores a couple of situations where the characters need to build trust. The Soviet astronauts don't trust the Americans. Dr. Floyd doesn't trust HAL. And Dr. Chandra doesn't trust Dr. Floyd. But only when everyone starts trusting each other are the astronauts saved, because they can't save themselves individually.

Software projects depend a lot on trust. Project managers have to trust that the developers are working hard and making progress. Developers have to trust that the testers are reporting legitimate problems and not making up stuff to look good. Designers and architects have to trust that the information provided by end-users is correct so that the application requirements are accurate. Without trust, everyone spends all their time checking up on everyone else and not getting anything done.

Things go wrong. Be prepared.

Bad stuff can happen. In the movies, the bad stuff included a political conflict and a homicidal computer. On software projects, many different things can go wrong. The smartest thing you can do is to consider the possibilities up front, and put a plan in place for mitigating the risk. Here's an example: for some projects, the "go live" date is critical. Customers might be expecting the software by that date, or there might be some other cost to your organization if the project is delayed. If that's true, then have a plan in place to minimize the pain if the project is delayed for some reason. Perhaps you'll need an easy way to communicate with those customers so they don't start calling. You'll feel a lot less stress if you have a plan in place for dealing with problems.

One final lesson from HAL:

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do." --HAL

Good idea!

  • Facebook
  • Twitter
  • Digg It!
  • StumbleUpon
  • Technorati
  • Del.icio.us
  • Reddit

Post a comment!

Formatting options
   
 
 
 
 
   

Wanna Subscribe?
Here's the RSS Feed

What the critics are saying...

Avonelle is a rare IT professional who can communicate with business users on a level they can understand, and who can recommend creative technical solutions that are in line with the business goals and the business budget. Avonelle is conscientious not only about meeting deadlines, but also exceeding her customers expectations around quality software while providing superior customer service. Avonelle is an inspiration to me.

Valerie Vogt, Director of IT Advisory Services @ Inetium