Skip to content
October 23, 2007 / Bob Black

Buggy Software

Jeff Atwood makes an interesting point over at his Coding Horror blog, that often times features are more important (from a financial standpoint) than fixing bugs. That people are more willing to pay for an impressive feature matrix than a laundry list of bug fixes that may or may not directly impact their work.

I agree.

In fact, in some cases not fixing bugs can play a bug part in the overall financial strategy. For example, I used to work at a software company (which shall remain nameless) which happened to have a monopoly in their market. There was literally nowhere else to buy similar software. Their software was horribly buggy, and so they encouraged customers to purchase a rather highly priced support contract entitling them to, more or less, call support.

In their defense, I don’t think this strategy was intentional – it was an (un?)fortunate side effect of what Jeff blogged about – to sell a product, new features are often more important than bug fixes. And boy did they have an impressive feature matrix. It was ginormous. Anyone comparing products would be silly to even consider a product with a lesser feature matrix, despite the fact that you might be able to save your data without risk of the application blowing up in your face.

I disagree.

On the other hand, in some cases, particularly for small startups, lots of bugs can mean instant death. I later worked as the Webmaster (back when it was still cool to be a Webmaster) for a popular web-based practice test provider. The entire staff was comprised of about 10 people, most of whom authored practice tests. The development staff consisted of me, my boss, and a contractor in another state that would occasionally do new development. With thousands of people using our site every hour, we didn’t have the resources to field calls about usability  or technical issues. The site had to always work – or else.

Balance and Counterbalance

Fixing a bug vs. just leaving it to fester has to be weighed against the time it will take, and the expected benefit(s), among other things. For example, when working in IT, we come across the occasional bizarre problem that only happens when a particular user right-clicks on a Tuesday under a full moon while winking her left eye. We could spend a week setting up a virtual environment and tinkering with different combinations of environment variables, installing and uninstalling different combinations of applications that may be the culprit, but is it really worth the time involved? Is the benefit there?

That depends too – if I worked for a hospital and the software in question monitored respiration or some such, it would most probably be worth the effort and time. But if it’s a Word template malfunctioning, let’s just reimage the user’s machine and move along.

The Feature Matrix

So, I think ultimately the feature matrix counts only towards influencing the initial purchase. If you have an impressive feature matrix but lots of bugs (like that company I used to work for), you can bet lots of users will start to think strongly about migrating to another product as soon as possible. And they’ll probably tell their friends not to even consider your product. And you’ll have a hard time getting positive product testimonies to plaster all over your web site.

Unless, that is, there isn’t another product for them to go to. In which case, you’re home free you nasty scoundrel, and you should offer a hefty support contract and start raking in the dough.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: