SUI: Software Under The Influence and The Limits of Liability

In a recent newsletter, I noted how companies are trying to get software companies to accept greater liability for damages caused by their software. Now, in general software companies get a pretty easy ride legally. Further, I think a greater sense of responsibility for their products would foster some healthier business practices in the industry. At the same time, I've seen a lot of people talk about that so I don't feel a pressing need to comment right now. Instead, I'm going to talk about why software companies shouldn't be responsible for the damages caused by their software. My thinking here is spurred by a particular comment by a General Motors executive who argued in the Wall Street Journal that they had to back their trucks, so software vendors should back their code. There are many ways why this analogy doesn't work. Here's my first:

Great engineering can't stop a drunk driver

When a drunk driver kills someone, no rational person would think to go after the guy who sold the car. Certainly, most IT professionals don't drink and program. Many software projects, unfortunately, do operate under the influence—the influence of stupidity. Or imperfect management. During my career, I've been more than a little aggravated by bad software. But 99 times out of 100, software created problems not because it couldn't do something but because it shouldn't have been asked to do something or because someone did something really stupid.

Let me start with an example where the problem was too much of a good thing. In this case, the customer had a lot of aggravation rather than a particular loss. This client did about $50 million in revenue through multiple entities. For reasons which to this day I can't understand, they decided to set up a chart of accounts with approximately 5000 revenue accounts. I asked whether anyone really thought this was controllable. The accountants were sure it wouldn't work. The CFO wanted the detail. Six months after go live most of the accounts were gone. Now, here the cost was mostly aggravation—delayed closings, incomprehensible financials and other things which could be blamed on the system. Of course, they system didn't force any one to be silly. People made the decision.

Another company actually lost sales when the implementation did not go smoothly. The problem here was that the customer insisted on refusing advice and then blamed others for the bad outcome. For example, the entire team, both employees and consultants, advised strongly that once things were live, nothing should be changed on the system for several months unless there was an absolute need to do so. Disregarding this advice, the customer went ahead and made some unnecessary changes for what they thought were good reasons. The system was brought to a crawl for days. If management asked, it was a problem with the new system. The software was at fault.

What's the overall point? In automobiles, its somewhat obvious what causes a crash. If an axles falls off a new car, we can be pretty sure it's a manufacturing problem. The problem in software is that, in the majority of cases, software is fundamentally not the problem. It's not the tool, it's the use to which the tool is put. Increasing liability won't change this.

November 28, 2008 | Email Us

| Next »

Red Three Consulting: Transforming Information Technology into Answer Technology