Should we spend less time discussing software bugs?

Is there a vague possibility that the technical community spends too much time complaining about software bugs? This rather startling proposition came up during a discussion with Paul Cunningham, of ExchangeServerPro fame.

Paul remarked that we seem to spend a lot of time finding bugs, reporting them, checking for workarounds, and describing them in blogs and other social media, all of which takes away from the normal work of IT professionals. He then wondered whether “it had always been this way?”

The simple answer is that it hasn’t. Although we might consider current software releases to be flawed, previous software was equally if not more flawed. For example, Exchange 2000 was a perfectly horrible release that combined with Windows 2000 and the first iteration of Active Directory to deliver a horrific deployment experience for anyone who had to upgrade from Exchange 5.5 and Windows NT 4.0. But the flaws (and there were many) of Exchange 2000 never received the kind of full-on publicity that Exchange 2013 gets today.

In fact, ten or fifteen years ago, news coverage tended to concentrate on features rather than problems. Limited communications and restricted outlets for discussions forced correspondents to focus on new functionality rather than bugs. Magazines weren’t interested in publishing in-depth articles about flawed features – it took them far too long to get an article through the publishing process and a fix might have been made available before the article appeared. And anyway, advertisers weren’t interested in publications that discussed problems – they wanted articles about new and exciting technology and “how-to” features to explain how to put the technology into action. Selling print ads was very important then.

Today, it’s all about page views as online magazines, blogs, forums, and other media jostle for prominence in a crowded Internet-centric marketplace. News appears fast and bad news is good for page views, so many articles are devoted to the exposure of flaws in products from mobile phones to laptops to enterprise software. Reports are written up in articles and blogs and flash messages are sent to the world via Twitter, Facebook, Yammer, and Google+ to let people know that new information is available. The news is subsequently explored, interpreted, updated, discussed, and generally dissected ad nausem.

Some of the exposure is good. For example, letting people know about potential security holes is absolutely the right thing to do. Calling companies to account when they let flawed and incomplete products into the market also delivers a service to the industry as it enables customers to make better buying decisions. But I sometimes wonder if those of us who write about IT sometimes make far too big a deal of bugs.

All software has bugs and all products will eventually expose their bugs to users. The question is whether the bugs that are discovered are important or not. I think that the best articles on bugs provide an analysis of why the bug has appeared, what it means in practice, and whether any workarounds exist. These articles help users to understand the impact of a bug in the context of their IT operations and decide what action they should take. Perhaps they can proceed with deployment or maybe they have to wait for a hot fix or software update. In either case, the decision is made in a state of knowledge.

I despair when I see a blizzard of “me too” posts appearing like a rash across blogs, all faithfully reporting the discovery of a new bug without adding an iota of intelligence or analysis to the debate. Too many people rush to publish without thinking about why a bug has appeared and what its impact might really be.

But software vendors don’t help themselves when they push software out that contains obvious bugs that should have been picked up during testing. These are the worst kind of bugs because customers expect that vendors will test their products thoroughly before release and depend on the quality of the testing to know when a product is ready for deployment. No customer can hope to be able to test a product in the same way or depth as a major software vendor as they don’t have the staff, the tools, or the expertise. So we need products to be released when they are ready and validated through testing and not to make an arbitrary date set by senior management or marketing.

Perhaps we should spend less time discussing some bugs (important bugs will always be visible) and more time thinking about the best use of technology to solve business problems. That, after all, is the real aim of the IT game.

Follow Tony @12Knocksinna

About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Technology and tagged , , . Bookmark the permalink.

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.