A software bug is a defect (bug) in computer software. A computer program with many or serious bugs may be described as buggy.
The effects of a software bug range from minor (such as a misspelled word in the user interface) to severe (such as frequent crashing).
In 2002, a study commissioned by the US Department of Commerce's National Institute of Standards and Technology concluded that "software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product".
Since the 1950s, some computer systems have been designed to detect or auto-correct various software errors during operations.
History
The term bug to describe a defect has been engineering jargon since at least as far back as the 1870s, long before electronic computers and computer software. For instance, Thomas Edison wrote the following words in a letter to an associate in 1878:
It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs"—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.
Problems with military gear during World War II were referred to as bugs or glitches.
Isaac Asimov used the term bug to relate to issues with a robot in his short story "Catch That Rabbit," published in 1944.
U.S. Navy Rear Adm. Grace Hopper, a computer pioneer, popularized a story about a moth that caused a problem in an early electromechanical computer. While Hopper was working on the Mark II and Mark III as Harvard faculty in about 1947, operators traced an error in the Mark II to a moth trapped in a relay. The moth was removed from the mechanism and taped in a log book with the note "First actual case of bug being found."
Reportedly, the operators, including William "Bill" Burke, later of the Naval Weapons Laboratory, Dahlgren, Virginia, were familiar with the engineering term and probably making a pun by conflating the two meanings of bug (biological and technical). Even if a joke, the story indicates that the term was commonly used in the computer field at that time.
Terminology
Mistake metamorphism (from Greek meta = "change", morph = "form") refers to the evolution of a defect in the final stage of software deployment. Transformation of a mistake committed by an analyst in the early stages of the software development lifecycle, which leads to a defect in the final stage of the cycle has been called mistake metamorphism.
Different stages of a mistake in the development cycle may be described as mistake,anomaly, fault, failure, error, exception, crash, glitch, bug, defect, incident, or side effect.
Examples
Software bugs have been linked to disasters.
Software bugs in the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s.
In 1996, the European Space Agency's US$1 billion prototype Ariane 5 rocket was destroyed less than a minute after launch due to a bug in the on-board guidance computer program.
In 1994, an RAF Chinook helicopter crashed, killing 29; this was initially blamed on pilot error, but was later thought to have been caused by a software bug in the engine-control computer.
Buggy software caused the early 21st century British Post Office scandal.
Controversy
Sometimes the use of bug to describe the behavior of software is contentious due to perception. Some suggest that the term should be abandoned, contending that bug implies that the defect arose on its own, and push to use defect instead, since it more clearly indicates they are caused by a human.
Some contend that bug may be used to cover up an intentional design decision. In 2011, after receiving scrutiny from US Senator Al Franken for recording and storing users' locations in unencrypted files,
Apple called the behavior a bug. However, Justin Brookman of the Center for Democracy and Technology directly challenged that portrayal, stating, "I'm glad that they are fixing what they call bugs, but I take exception with their strong denial that they track users."
Prevention
Preventing bugs as early as possible in the software development process is a target of investment and innovation.
Language support
Newer programming languages tend to be designed to prevent common bugs based on vulnerabilities of existing languages. Lessons learned from older languages such as BASIC and C are used to inform the design of later languages such as C# and Rust.
A compiled language allows for detecting some typos (such as a misspelled identifier) before runtime which is earlier in the software development process than for an interpreted language.
Languages may include features such as a static type system, restricted namespaces, and modular programming. For example, for a typed, compiled language (like C):
float num = "3";
is syntactically correct, but fails type checking since the right side, a string, cannot be assigned to a float variable. Compilation fails – forcing this defect to be fixed before development progress can resume. With an interpreted language, a failure would not occur until the statement was executed (much later, if ever, during runtime).
Some languages exclude features that easily lead to bugs, at the expense of slower performance – the principle being that it is usually better to write simpler, slower correct code than complicated, buggy code. For example, Java does not support pointer arithmetic which can be very fast but may lead to memory corruption or segmentation faults if not used with great caution.
Some languages include features that add runtime overhead in order to prevent common bugs. For example, many languages include runtime bounds checking and a way to recover from out-of-bounds errors instead of crashing.
Techniques
Style guidelines and defensive programming can prevent easy-to-miss typographical errors (typos).
For example, most C-family programming languages allow the omission of braces around an instruction block if there's only a single instruction. The following code executes function foo only if condition is true:
if (condition)
foo();
But this code always executes foo:
if (condition);
foo();
Using braces - even if they're not strictly required - reliably prevents this error:
if (condition) {
foo();
Enforcement of conventions may be manual (i.e. via code review) or via automated tools such as linters.
Specification
Some contend that writing a program specification, which states the intended behavior of a program, can prevent bugs. Others, however, contend that formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.
Software testing
One goal of software testing is to find bugs. Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable the longer a product is tested and developed.
Agile practices
Agile software development may involve frequent software releases with relatively small changes. Defects are revealed by user feedback.
With test-driven development (TDD), unit tests are written while writing the production code, and the production code is not considered complete until all tests have been written and complete successfully.
Static analysis
Tools for static code analysis help developers by inspecting the program text beyond the compiler's capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes when writing software.
Instrumentation
Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE"), or provided as tools. It is often a surprise to find that most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.
Open source
Open source development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus's law says that popular open-source software has more chance of having few or no bugs than other software, because "given enough eyeballs, all bugs are shallow". This assertion has been disputed, however: computer security specialist Elias Levy wrote that "it is easy to hide vulnerabilities in complex, little understood, and undocumented source code," because, "even if people are reviewing the code, that doesn't mean they're qualified to do so." An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian.
Debugging
Debugging can be a significant part of the software development lifecycle. Maurice Wilkes, an early computing pioneer, described his realization in the late 1940s that