Buggy software: Why do we put up with it?

This is a guest post by Michael Kassner via TechRepublic's IT Leadership blog.

During one of the breakout sessions at TechRepublic's Live 2010 Conference this past week, I was questioning why we put up with software that has bugs and vulnerabilities. To IT-security types like me, it's a concern. Eliminate bugs and you shut the door on most malware.

After that particular breakout session, Toni Bowers, Head Blogs Editor for TR, and I talked about my concerns. She suggested that I pass what I learned on to you. So, here goes. I cajoled the "software savvy" TR writers into answering the following question:

Consumers would never accept a car or other traditional goods that are flawed, yet they are willing to buy software that is. Why do you think that is?

Here are their answers. I hope you find them as interesting as I do:

Chad Perrin

The question of why software vendors produce buggy software and why consumers accept it has no simple answer. The reasons vary from incompetence plus overconfidence to being the dominant business model at the other extreme. Here are some of my thoughts:

• The dominant business model in the software industry is one that creates and relies on otherwise unnecessary complexity. That complexity both creates bugs and hides them from view. Paraphrasing C. A. R. Hoare, there are two ways to build software: Make it so simple that there are obviously no bugs, or make it so complex that there are no obvious bugs. The former is much more difficult and does not lend itself well to enticing people to upgrade to the next version.
• People are so focused on feature marketing that they do not stop to think about bugs until it is too late. After generations of this, and of the problem getting worse all the time, end users have developed a sort of Stockholm Syndrome with regard to buggy software. They believe it is normal, expected, and inescapable.
• Features and bugs act very similarly a lot of the time once software exceeds a particular level of complexity. They do things that are surprising, or at least unexpected. People grow used to this until they become inured to surprise without the surprising behavior being reduced at all — in fact, it only gets worse. "It's a feature, not a bug" starts to sound reasonable and believable.

Chip Camden

Having worked in auto parts for several years, I can tell you that very few cars roll off the assembly line without any flaws. That's why they have a thing called recalls.

Furthermore, a serious flaw in an automobile can cost someone's life. That usually isn't the case with software, and where it is the case (medical, missile guidance, aircraft navigation), then the extra expense of a higher attention to flawlessness is considered worthwhile.

Ultimately, it's market-driven. We could make software that performed to much more exacting tolerances, but it would be much more costly. The buying public is content to pay a near-zero cost for "good enough" rather than putting a dent in their wallets for "flawless." [Editor's note: you can read more from Chip Camden in TechRepublic's IT Consultant blog.]

Erik Eckel

I think the software industry is very different from most any other. Vendors must try writing software that will work on multiple platforms (Linux, Windows, Mac) and be used by a variety of users with greatly differentiated skill levels at companies working in numerous different industries. That's a pretty tall order.

Imagine trying to make a car that could be driven by a 5′4 woman or 6′5″ man that could run on gasoline, diesel, or propane; while also possessing the ability to carry up to eight people or 6,000 pounds of payload. Oh, and it must get 28 miles to the gallon and cost less than $25K and go 100,000 miles between tune-ups.

You couldn't do it!

So, I feel for software manufacturers. The Intuits, Microsofts, Apples, and Symantecs of the world have a wide constituency to satisfy. Someone's always going to be complaining.

I think the 37signals guys may have it best. In their current best-seller ReWork, they note that one of the keys to their success is saying no to customers and limiting the amount of features they include in their software programs.

I think there's a lesson there for all of us. [Editor's note: You can read more from Erik in TechRepublic's Macs in Business blog.]

Jack Wallen

The answer is very simple: Marketing. If you ask the average consumer (those who buy the bulk of computers) if they knew there was an operating system out there far superior, safer, and more reliable than the one they used AND it was free, they would react with surprise. Their first question might be "Why didn't we know about that?" The reason is because Microsoft is a HUGE company with a HUGE PR budget and the ability to shove advertising down the throats of the consumers.

To continue with your analogy:

Tesla has a roadster that is 100% electric, can go over 300 miles on a single charge, can go from 0 to 60 in 3.7 seconds — yet the majority of people don't know about it. Why? Marketing. If one Linux company could start to produce witty, well-done television commercials things would quickly change.

But think about this: Linux has done fairly well for itself without having to spend a penny on advertising (relatively speaking). Word of mouth has been a powerful alley to the Linux operating system. However, in order to raise it to a higher level, PR and marketing will have to be used. [Editor's note: You can read more by Jack Wallen in TechRepublic's Linux and Open Source blog.]

Justin James

Some thoughts that come to mind (as someone struggling with a phone heralded by others and the media as a "miracle phone," but it is plagued with problems):

• "No warranty, express or implied" is attached to every piece of software ever made and is enforceable. Consumers know that they have zero rights, so they feel happy when it works.
• "Gadget lust" blinds people to issues. People don't want to admit that they bought a piece of junk, so they just deal with the problems and tell everyone how much they love the software/device/etc.
• In corporate environments, the people who live with the bad software are often the people who do not pick it. Those who did select it sweep the problems under the rug because it makes them look bad, or they feel it's a question of "stupid users" who "just don't get it."
• Too many problems do not appear until whatever initial return period of contract cancellation period is over.
• People expect to have problems.
• People assume that the problems are their own fault ("I'm too dumb to use this right!").
• In corporate environments, many products require a lengthy and expensive integration process; there is no way to accurately judge their quality until that is done, and afterward, it is often not clear if the base product or the integration work is the root cause of problems. To make matters worse, once you dump, say, $150,000 into customizing a $200,000 package that you spent $50,000 on hardware to support, do you really want to say, "gee, it looked good when we started, but this is a dud, let's dump it"?

Overall, it's a combination of people feeling helpless on the user end of things, and the decision makers being unwilling or unable to do anything about it once a commitment is made. [Editor's note: You can read more by Justin James in TechRepublic's Programming and Development blog.]

Patrick Gray

I think there are two factors at work that would cause me to question your premise:

Perceptions of software "flaws" are often based more on market saturation than technical elegance.

Most mainstream technical products (hardware and software) seem to have a higher incidence of flaws because they have a higher user base. This is the classic "Windows is buggy versus [a more obscure OS]" argument.

I don't think Windows is inferior, it's just a mass-market product and thus gets used and abused by the highest percentage of the population. Because Mac OS X has gained traction, it's now getting hit with malware as more people use the software rather than due to some inherent flaw.

There are considerations that outweigh flawed products, mostly getting valuable features early.

I think technical elegance often becomes second fiddle to other concerns at both a corporate and personal level. Why? We want new features and are willing to put up with partially baked software. This extends to your automotive analogy as well.

I bought a new motorcycle from BMW in its first model year (ever hear the old bromide never to buy the first model year vehicle?). The bike has had four recalls, including replacing the front axle (a front axle failure at 80 mph would be bad). Despite this product having flaws, the trade-off of having an extra year's riding was worth it to me.

If we all wanted perfect and bug-free code, first and foremost, we'd probably all be running MS DOS or a text-based Linux that hadn't had any features added in a decade. [Editor's note: You can read more by Patrick Gray in TechRepublic's IT Leadership blog.]

Rick Vanover

While software quality should be the first priority in whether or not we implement something, many times IT customers have their hands tied. Simply forgoing a piece of software if all offerings will not meet their needs will not be an option.

The natural alternative is to develop something in-house, but that too, may be cost prohibitive. This is an age-old battle of having our hands tied in a way to get pushed along to new products, and history has done nothing but continually confirm this for us.

One example is the file server market, Novell NetWare is still a superior file server product to Windows NT, 2000, 2003, or 2008; yet we all know which way the market and broader supported configurations went. There is no simple answer on how we can address this, in my opinion. [Editor's note: You can read more by Rick in TechRepublic's Network Administrator blog.]

Final thoughts

It seems we the users want the latest and greatest software, even if it means accepting buggy code. Do you agree with the TR gurus? I know we all are anxious to learn your opinions, so let them fly.

Chad Perrin wanted me to mention that he has a lot more to say about this subject. Please look for his article in the IT Security blog of TechRepublic.

Excerpted from Buggy software: Why do we put up with it? ZDNet