What is a software bug?

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program’s source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy.

— Software Bug @ Wikipedia

Why is software so buggy?

I truly want to know why software is so buggy, so I am seeking out theories and summarizing them here.

“Most bugs arise from mistakes and errors made by people” states Wikipedia, and I concur. With a few rare exceptions, bugs result from human decisions.

From quora.com

“It’s all in the cost-benefit analysis. The cost of writing bug-free software is extremely high, and the cost has a lot to do with time, not just developers.”
— Joe Masters Emison

“Software is ‘so buggy’ because software development is a very complex activity to meet vague requirements with an unknown solution under tight time pressures. As a result most developers find the right solution to meet the user’s requirements through a series of increasingly accurate approximations.”
— Murray Robinson

“Developing Software is inventing on a schedule with imperfect human beings …. That is, every program you’ve ever used has been created from scratch, or uses pre-existing components that were themselves created from scratch. Consequently, mistakes creep in …. So ultimately the answer to your question is that perfection is hard.”
— Pierce Wetter

Why is Computer Software So Buggy? @ quora.com

Why producing good software is difficult

See Why producing good software is difficult — thoughts by a variety of thinkers, compiled by Edward Tufte.

Excerpts:

We need software as a commodity. Creating software is an art. Therein lies the problem.

Programming is an intensely creative process. Not only the software design — I mean the actual coding itself. There’s frequently no clearly proper way to do something — finding the right way to do it requires creativity. It requires a person who’s something of an artist. There simply aren’t enough artists around to make consistently good software.

Until we figure out how to make programing a non-creative task — make it like brick-laying or prefab construction — we’ll be stuck with bad software. The guys who are creative enough to do great work end up becoming designers, leaving legions of less capable individuals to do the construction.

Could the pyramids have been built if all the laborers needed to be architechts too? Until we figure out how to turn programmers into laborors — how to commodotize them — I think we’ll be stuck with bad software.

— James Acres

The information industry is managed by those who are essentially ignorant of programming practice. Taking Mr. Acres contribution to heart, what is really needed is to reform perception of what is good and what is bad. Craftsmanship is irrelevant.

— Ed Mikula

Studies have been performed on even simple applications and found how quickly bugs creep in to simple software packages. Even dedicated senior programmers have a typically rate of 2-4 bugs per 1,000 lines of code, so a million line program is typically developed with 2,000-4,000 defects (I have worked for multiple major vendors, not just SAS.) Some software vendors are much more willing to release software with minimal testing and others will allow much more time prior to release, still testing can only catch so many of the issues (maybe 95% at a good company), so you are still stuck with many defects in a complex program.

Bottom line- software is one of the least purpose specific products on the market (compare with a car, screwdriver, skateboard, bicycle, etc.) and as a result, will continue to be very buggy for some time to come. Think of very specific purpose systems like Tivo and you will see software of much higher quality due to limited usage patterns. Use a skateboard as a hammer or a car as a bulldozer and watch how long they meet your need.

— Stephen McDaniel

Stephen McDaniel provides an excellent summary of why software is bad. However, this changing, and a lot of software today is becoming quite good.

With API’s or standard protocols today’s software enables third parties to extend, or enable, the software beyond the creator’s ability, imagination or energy.

Another factor is taking place in software development: test driven design. Software is written by first testing it. This has three big advantages: bugs are reduced, better development documentation can be produced(via the tests) and feature creep is possibly stymied.

— J. Weir

Software is bad by what metric? Compared to 10 years ago [1997], we have software functionality that is incredibly advanced. I think the truly distinctive feature of programming is cultural. Programming is, currently, a mixture between craft and engineering, and academic computer scientists are, by and large, disdainful of both. For a long time, I accepted the standard critique of software as bloated, buggy, lacking elegance and rigor etc. But I’ve become dubious of this critique which more and more reminds me of the Modern Architecture complaints about buildings that were comfortable and usable.

— victor yodaike

I have experienced problems with technical types and non-technical types not being able to effectively communicate with each other. There isn’t a common vocabulary and in the end programmers create software for themselves. A big part of the problem is software is an abstract thing, making the leap to a real product is extremely difficult.

— Doug Cleary

Ultimately software is buggy because as consumers we want it cheap, pretty and we want it now, and we’re much more willing to live with the bugs than we are to wait longer, sacrifice functionality and pay more. The software manufacturers are just giving us what we as consumers want, and we’re voting not with words but with dollars.

— Jack Slowinski

Depending on whose assessment you read, anywhere from 50% to 75% of all software projects fail, either fully or completely. I think that referring to these as “bad” is reasonable, and furthermore that generalizing as far as to say that “more software is bad than not” is legitimate: I can’t think of another discipline in which that high a failure rate wouldn’t be scandalous, excepting advanced R&D and other experimental situations.

I believe that the single factor most responsible for the poor quality of most software is that the predominant software project methodology continues to be based on the waterfall model, where you first obtain requirements, then go though various levels of analysis, design, and review, and finally (after weeks to months of analysis and formal design) get down to implementation.

… The simple fact is that most clients, customers, and end-users really don’t know what they want. They have many things that they think that they want from an abstract, theoretical point of view, but which turn out not to be as useful practically as the theory suggested. They also don’t know about things that they would find useful, if only they were aware of them — but, lacking adequate knowledge of the state of the art in software (and particularly human-interface) design, they can’t even conceive of them.

— Jon Pastor

Fred Brooks’ influential 1986 paper, ‘No silver bullet’, explains why software production is inherently difficult, and why there are no significant productivity-improvements to be expected anytime soon. His main argument is that problems have an ‘essential complexity’ and an ‘accidental complexity’. Accidental complexity is due to the imperfect nature of our tools, our representation methods, our programming languages. Essential complexity is part of the problem, and we can’t do much about it. Brooks argues that as of 1986, accidental complexity accounts for less than 10% of the software development effort, and since all we can improve is related to this accidental complexity, we can’t hope for significant overall gains. This prediction seems to have been confirmed by the last 21 years of developments.

— Laszlo Kozma