Developer's Toolkit

Blog archive

When Good Software Goes Bad

I've been reading a bit recently about how software companies continue to "stick it" to customers in the course of doing business. Even if you don't experience such things personally, you can read examples daily on advocate sites such as Ed Foster's Gripe Line at (and most recently,

Well, I'm ostensibly a journalist, and I'm also a consumer and buyer of software. But I'm also a software corporate guy, a product manager for software bought by businesses. If anyone can bridge the gap between what goes on inside a corporate decision-making process, and how it comes out to the buyer, it should be someone like me.

To protect the innocent and perhaps not-so-innocent, let's consider a hypothetical situation. Changes in licensing policy are one of the common areas of aggravation for many software buyers. Let us say, for the sake of discussion, that something along the lines that Ed Foster reports has occurred. You have made a software purchase, and its role is important for your development process; for example, defect tracking or source code control. Your purchase price was $50,000. This software functions quite well for two months, until Microsoft releases the next service pack of the Windows operating system, and then stops working.

Your vendor has released an upgrade to that software that addresses the problem. However, because you chose not to buy the 25 percent maintenance or subscription or whatever they call it, you have to pay an additional $35,000 to "upgrade" to the new version. The end result is that you paid $85,000 in order to use the software for longer than two months.

On the surface, this looks like evidence that there is a concerted effort to extract more money from you while providing little or no additional value. But let's take a look at what likely happened inside the software vendor that led to this outcome.

It's entirely possible that no one knew that the Windows service pack would break the software. Even if it was known, that knowledge was confined to the engineering staff that is far more interested in finding and fixing the problem than in how it will be sold. However, they fixed the problem in the current code base, which also includes new features, and determine that it's too expensive to retrofit it into older version. But now you've paid for something that you didn't plan on.

So why isn't it fixed once it is uncovered? That has more to do with corporate inertia than malicious intent. Let's say that you start complaining. Who do you complain to? The goal of the sales team is to maximize revenue, making it unlikely that your account manager will give you much more than sympathy. And in his defense, you've received a new version, with new features, for your money. If you are a sufficiently large and active customer, perhaps you can get the attention of an executive, which might gain you nothing, or perhaps a discount on a future release.

I'm not defending any of these practices. But it is possible, even likely, that no one is attempting to stick it to the software buyer. Rather, the real culprit is one or more broken business processes within the software vendor.

And what this really means is that the way we buy and use software is also broken. Part of the problem is our own expectations as software buyers. We want to own the software, and have control over its use. But there's a price to pay for ownership. To pay for the non-recurring engineering costs, most commercial vendors have to release new versions at least annually. New versions add features; after a few years, more and more of those features add value to fewer and fewer users. And it still costs a lot of money to keep up with these versions, even as they add less and less value.

The answer might be software rental, if we can get around our ownership hang-up—and if software vendors can reduce their dependence on the big revenue pop that comes with releasing the next great version. But software purchase (or "license to use," as some vendors call it) is simply a recipe for dissatisfaction for the buyer, and a source of financial risk for the vendor.

Posted by Peter Varhol on 12/18/2004 at 1:15 PM

comments powered by Disqus


Subscribe on YouTube

Upcoming Events