Business-focused custom software

"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!