Buggy software: Why do we put up with it?

Buggy software: Why do we put up with it?

Summary: TechRepublic writers tackle one of IT's never-ending questions: Why do we put up with buggy software? Here are a few answers.

SHARE:

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.

Topics: Linux, CXO, Open Source, Software, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

55 comments
Log in or register to join the discussion
  • RE: Buggy software: Why do we put up with it?

    In the past a lot of it was feature counting which a number of magazines did (including most of the Ziff Davis family) as a way to review software. This is the model that caused articles to say "Microsoft word is best since it has all these features" ignoring that at the time they did not integrate together and were buggy.

    Today, I blame open source! For a number of years I have had a product idea that I have shopped around. Unfortunately, it requires OS support so Linux is the logical target. The problem is that the design also is for a piece of software that is extremely easy to use, and has the advantage that if there is a bug it would become obvious to the user. When I look for funding, both the VC's in the open source space as well as the guru's (including at least one ZdNet blogger) have suggested making it harder to use and less reliable so I can charge for support! So far I have refused to take this approach, so the product is stillborn.
    oldsysprog
    • Are you really surprised?

      @oldsysprog
      The folks in the VC arena - regardless of whatever platform you've got in mind - aren't there to just give away a boat load of cash. Those days are gone with the Dot Bomb era. These days, if you expect them to plunk down a chunk of their money on your project, they kinda expect to see something in your business plan that includes this "evil" P word in your product's future. You know the one - PROFIT...

      How else are they going to make back their investment and someday maybe see some extra cash in their pockets as well?

      Given the only acceptable means to make money on Linux is to charge for support, a product that's dead simple to use, and it's obvious when there's a problem, you're going to find most, if not all of the VC people telling you the same thing.
      Wolfie2K3
      • RE: Buggy software: Why do we put up with it?

        @Wolfie2K3
        "Given the only acceptable means to make money on Linux is to charge for support".
        Pardon? You can of course charge as much as the market will bear - regardless of the OS it runs under, and whether it calls up other applications that are open source - provided that it is clear that the other applications it uses are not what you are selling. This includes software that runs on any of the open source OS's Linux BSD, UNIX derivatives...
        So the only question is whether you can persuade potential customers that they wish to pay a viable amount for the offering
        shtromer
    • If your software requires VC funding it will have bugs.

      @oldsysprog: It doesn't matter how easy it is to use. VC funding implies a certain level of complication. Thus your software, easy to use or not, will have bugs.
      ye
      • RE: Buggy software: Why do we put up with it?

        @ye: Yes all software has bugs, what I find disturbing is that both VC's and leaders in Open Source have advised me to make the software harder to use, and essentially have more bugs. If this is the future of sofware with open source, then I don't want to be using it.
        oldsysprog
    • RE: Buggy software: Why do we put up with it?

      @oldsysprog
      What nonsense. I use some extremely highly-priced software that runs under open source. The vendors charge (typically) 15% for maintenance, but this is for new features rather than bug fixes (they also fix bugs, but these days the bugs are "irritators" rather than project- or security -critical matters)
      shtromer
  • Software is multiple complexity level higher than manufactured parts or car

    Formally specified pieces of software, that is pieces of software that are proven to function according to specifications can have bug, even thought they have very restrictive specifications.

    But that is difficult, not totally bug proof, expensive are limited to small part of the software industry.

    Not bug proff because you only validate against a set of possible states/interactions. If you fall outside of that validation domain, bugs can re appear. You must then ascertain that you correctly modelized your environment, which is a huge problem by itself.

    Difficult because you must very carefully modelize the environment, the functionalities you want to offer, the restrictions you are willing to place upon them, the tests you will perform to validate all this choices...

    Expensive because tools to support all this cost a lot of money, but this is nothing compared to the pay check you will have to give to architects engineers and the like to perform all of this activity, plus those to validate it.

    Limited to a small part of the industry because as soon as you introduce user interaction, the realm of possible state for your software simply explodes. If you have n functionalities and you consider a sequence of p interactions, you have n^p possibilities with n=p=20 that make 10^26 possibilities. A software with only 20 features is a really small software. But if a tester has the possibility to test one sequence every second, and if you employ all India to perform the tests you will need 3 billion years to finish the test campaign. Interactive software a impossible to prove. You can prove subset of them if your architecture is properly done. But this filed of computer science is new; at least its introduction within the industry is quite recent. ( for instance intel began proving its chips only after the pentium bug ). Architecture of current software on the other hand is old. Windows NT ? architectured in the very early 90s, Oracle ? in the 70s/80s. Of course these architecture were revised over time, but you can never clean the slate because its too expensive, too difficult, produces immature software, and jeopardize market shares...

    Bugs are consubstantiation with consumer software. procedures and tools to have more control over software quality are diffusing within the industry, but they won't change radically things in the near future, and won't eliminate bugs anyway
    s_souche
  • It's just because of market phase: early adopters versus laggards

    Early adopters will accept having to manually prime their 1920s car with fuel, warm the brakes up with a candle before setting off.
    But laggards won't buy until the cost of ownership (in terms of self-tech support) is low.
    Cellphones are packed with software, but most non-smart phones are very stable. If they aren't it's as good as buggy hardware, and people won't buy the phone.
    Computers are going the same way. In most organisations, they currently employ people to keep the unreliable software running, like at one stage companies had a team of mechanics keeping their cars going. But it will change.
    stevey_d
  • RE: Buggy software: Why do we put up with it?

    I asked that question to a ZDNet blogger a year or so ago and he said that it's impossible to write bug free software. I'm not a programmer, so I can't really comment on the subject. However, here is a link to an article I read a long time ago that says it can be done. http://www.fastcompany.com/magazine/06/writestuff.html
    riverab
    • They don't say it can be done

      @riverab@...
      They say that a program that has a very limited, predicted function can do that. You can right a bug free square root program, and prove it is bug free. But you cannot write a program that accept complex interaction and prove it. At of today you cannot prove an asynchronous program is bug free.

      Even in the article you point to programs are not bug free, as they list the number of bugs found. And these bugs were found from 1993 to 1996 during.... 27 missions.
      s_souche
    • RE: Buggy software: Why do we put up with it?

      @riverab@...

      The problem is that the people who wrote and edited that article have no idea what they are talking about.
      mejohnsn
  • RE: Buggy software: Why do we put up with it?

    Of all the people you asked Eril Eckel seems to have the best grasp of software. I don't know who Jack Wallen is but he seems to be the one with the least amount of knowledge on software. Actually he seems to be quite out of touch with software, business, and customers.

    The reason we put up with buggy software is because its not a matter of life or death generally speaking. If flash crashes on my browser it doesn't harm me in any way. I open the browser again and continue browsing. Software can be quite complex and is prone to human error due to just a simple typo in the code or going one digit off in an algorithm.
    Loverock Davidson
    • RE: Buggy software: Why do we put up with it?

      @Loverock Davidson

      If you don't know who Wallen is, then why didn't you Google the name before commenting? YOU must be the one out of touch with the times to forget about doing this.
      He is a self-confessed "glorified cheerleader for Linux". This would explain why he blames everything on marketing.

      That said, he is not that far off: marketing really is a significant factor. But where he is wrong is in his supposition that this "superior, safer, and more reliable" even exists.

      Linux is "superior, safer, and more reliable" ONLY if you are not trying to do the same many things people routinely do with Windows.
      mejohnsn
      • RE: Buggy software: Why do we put up with it?

        @mejohnsn

        Hmmm... I do many things people routinely do in Windows on Linux and so far it has proven to be superior, safer, and more reliable. While the safer and more reliable factors are things that can be backed up by facts, the idea of a SUPERIOR OS is completely and absolutely opinion. Linux, openSUSE in particular, is superior to Windows or Mac OS X for me. It works the way I want, it is free, it does every single thing I need to do and is reliable and secure. But Windows or OS X may be superior to someone else. My friend is a HUGE Microsoft fanboy and is a much bigger gamer than I am. Windows has the strangle hold on games so that is one reason it is superiour for him. It can easily be argued that DOS or OS/2 are superior for certain applications and they are.

        The automotive analogy is something I have actually been thinking about and is right on the money when it comes to the OS space in computers in particular. Oil, or gasoline I should say, is the monopoly on car fuels and the vast majority of the cars out there are run on it. Does that mean it is a superior fuel? No. Oil is analogous to Microsoft and cars are analogous to all the software companies out there. Software companies do not write software for Windows because it is superior, they write for it because they would not make any money if they didn't. If Linux had say a 25-30% share of the market, things would be very different.

        But it is not really marketing, it is to a degree, but the bigger factor is still synonymous with the automotive analogy. Things are stuck in an uncompetitive cycle of limited options for the average Joe (or Jane). If someone goes to buy a car, they will be hard pressed to happen upon one that isn't powered by some sort of oil derivative. Those that do either stumble upon it and it is too different/new for them to be interested in, or they sought it out being specifically interested in it. Like wise, if someone goes to buy a new computer, they will be hard pressed to find one that is not running Windows unless they stumble upon one or they seek it out. And in that respect some people will seek out Macs and you know why? Because of marketing. Until Apple started their T.V. ads I never saw one Mac in a store. Now my Best Buy has a whole area set up for them. And that advertising gives them credibility to people who otherwise would not know anything about them. Does it mean they are better than Linux which they might have seen on a random netbook somewhere but otherwise have never heard of? No, but those commercials sure make it seem that way in their head. Now if the Tesla company had some commercials on T.V., then a lot more people would be interested in them, but as it is not that many people have and so only those who know about them and specifically seek them out really care.

        But in reference to Linux, it has done pretty fricken well for something that is available for freeand has no real advertising other than word of mouth. That one or two percent may not sound like much, but compare that to the 5 odd percent market that OS X has given Apple's vast amount of T.V. commercials. Linux also continues to experience growth unlike some OSes... but I suppose once you have completely saturated the market there is really only one way to go and it isn't up...
        hito_kiri
  • RE: Buggy software: Why do we put up with it?

    When the dominant player in the base market (the OS) is a monopoly, users think that there is no alternative to buggy, slow and cludjy bloatware. "Oh, computers just do that. Go ahead and reboot."

    If users ever got a taste of a stable, lean and modular OS, they would never even think about going back.
    CarlosHawes
  • Where to start...

    You can find a million articles and papers about this topic, with very different opinions. A few that pop to mind:
    - We are a much younger industry. Software development as an industry just hasn't have the chance to mature to the point were our methods are beyond craftsmanship as other industries such as civil construction has.
    - We do not use assembled components. If you think about it, cars and planes are built from pre-assembled components that have been tested individually and used in previous successful products. So in a way the only place were defects can be introduced is in the assembly. In software we are not there yet and some argue we will never be because of:
    - Software technology changes too fast. Although this is very controversial, most people tend to agree that even though the underlying technology hasn't changed that much (we are still using what are basically the same Von Neumman computer architectures from 50 years ago), the changes in software technology and the introduction of new highly disruptive technologies such as networking, mobile computing, GUI, SOA, have made us have to reinvent most of our methods and tools again preventing much needed maturity
    - Software is everywhere. The fact that software must be built for so many different domains and environment makes it hard to achieve a level of specialization that will result on proven tools and techniques to be developed that will prevent defects on the next generation. In other words, software for cell phones is too different from software for accounting which is very different form the software that goes inside the space shuttle and hence what we know in every attempt does not cross domains.
    -
    - Education focused on programming and not engineering. The problem of software development is that the methods and techniques you use to build a "Hello World" program are completely inadequate when building an ERP. But still education is focused on teaching programming first and then software engineering as an afterthought and usually in a 1 semester course. This creates generations of software developers that do not understand the consequences of building software the way they do and fail to scale up to the required attributes of enterprise software such as quality, reliability, maintainability, etc.
    - Quality is expensive. Zero defects is possible, as the people that perform clean room software have demonstrated, it just takes a lot of money, stable business and organizational environments and highly trained and experienced people. You can't test for every condition in any complex software, but you can certainly attempt no defects are introduced in it's construction process.
    - Software is etheral: Unlike car building which is based on physical models, software are based on mathematical ones, and as such are much harder to visualize and test with traditional industrial mechanisms. Some have successfully bridged this with techniques such as model driven development (like NASA) that allows them to ensure the main behavior of the software is ensured from inception and test several conditions. This, of course, does not ensure there are no defects, only that the program will behave like the model (which is simpler to build and test).

    From a market perspective, I agree we have become "trained" to expect defects in our software and live with it as long as it is not critical but I can think of several companies whose poor quality products have built them a reputation they can never shake of which in many cases has lead to their demise.
    raul.vejar1
    • Disagree

      @raul.vejar@... Increasingly developers are using pre-assembled components. Ever hear of .NET Framework?
      MSFTWorshipper
      • RE: Buggy software: Why do we put up with it?

        @MSFTWorshipper

        I was referring to components that handle specific functionality such as handling graph rendering or email sending.
        .Net is a more generic purpose framework meant to build components that provide the specific functionality. Even using .net u still have tons of code to produce to get any useful functionality which will introduce more defects. The point here is to use components that provide the required functionality from endpoint to endpoint as to avoid having to write that code yourself and avoid introducing new defects.
        Sorry if there was any confusion in this point, component is a very generic word, I should have been more specific.
        raul.vejar1
      • RE: Buggy software: Why do we put up with it?

        @MSFTWorshipper

        You miss the point. The example he gave of assembly of components was still fundamentally different. The difference was that if you find a bug in the assembled product, it is almost certainly NOT in the components, it was introduced by the assembly.

        .NET Framework is nowhere near that level of reliability. You must not assume that the bug was introduced by the assembly, even if that working assumption is OK for the first 15 minutes of debugging.
        mejohnsn
    • RE: Buggy software: Why do we put up with it?

      @raul.vejar@...
      Even though I am only an economist, I concur with your line of thinking. I do, however, believe that (at least) attempting to make a high quality (almost perfect;-)) product only appears to be expensive. Correcting mistakes on a faulty product (no matter what it is) later comes at high cost... maybe even the loss of market share or worse. Profit at all cost is not working, ever.
      The consumer is not stupid. In a communist world consumers have little or no choice to buy junk or get nothing... Microsoft e.g. has created a situation similar to that in a communist environment for all of us. WE ALL had LITTLE CHOICE, but to follow their flag, and still MS can almost dictate any type of junky OS on 90+% of all computer users... Think about it.
      No car-, washing machine-, TV- manufacturer has that kind of clout. No other company has it. It does scare me.
      Thanks, and forgive my bad command of the English language.
      IKE:)