If Software Ate the World, Why Do I Feel Chewed Up and Spit Out?

Before you installed that last software platform, you were sure it was going to solve your customer service issues and give you that long-promised “flexibility” to your stakeholders. Until the next platform you installed.

In August 20, 2011, Marc Andressen, of NCSA Mosaic and Netscape fame, published a seminal thought piece about how software was eating the world which appeared in the WSJ.

A funny thing happened in the after-party, however.

Software did indeed eat the world. The influence and decisionmaking power of developers within organizations of all sizes is on the rise.Most people who wouldn’t know a sorted linked list if it hit them in the head really get a kick out of talking about their “algos”. As buggy and bloated as most software is, that is not even the biggest problem that most people have. Think about the last 3-4 outages you had at your company.

The biggest problem with software, without question, lies at the intersection of people, process, and technology.

There are about 1,000 different ways things can fail in a company which relies on software. Here are just a few:

Hopefully if she spits this out, it will won’t be near you….

• You bought software when you should have built it in-house, as its your core competency.

• You are proud of software it took 6 months to build when you could have easily acquired it off the shelf, as its not your core competency.

  • What’s worse, you could have gotten it for free.

• Then, your only competent developer left.

• Worse, all your incompetent developers stayed.

  • And … you aren’t certain you can tell the difference.

• You think your deadline changes how software is developed, and try to predict 5 releases ahead.

• You don’t understand how much you can do and so are just happy anything gets done at all.

  • You’ve given up on predictability because you view your only option as fighting.

• Your engineers all bought catcher’s mitts because new requirements fly in every day from every direction.

• Your engineers are coming up with their own requirements because no one talks to them.

  • You just assume the engineers know what the business wants to do.

There are so many ways that your software and people processes can fail, that it’s overwhelming to even think about.

IF YOU CAN’T PRECISELY IDENTIFY THE ROOT CAUSE OF THE PROBLEM, HOW ARE YOU SURE YOU WON’T MAKE THE PROBLEM WORSE? IS THIS THE “PROMISE OF SOFTWARE?”

After two decades in the technology industry, I still have not seen every way that software can fail. But I guarantee, I have seen more than most …