A computer bug is an error in a computer program.

A feature is a bug that the company has no intention of fixing.

Microsoft does not like to call them bugs. They have other terms, such as "issues" or "glitches".

No one likes to talk about bugs.

When we discovered a roach in our hotel room, and brought it to the hotel clerks attention, he said that they did have problems with Palmetto bugs, not wanting to say the word roach.

In the early days of computers, the first documented computer bug was a "moth" that had short-circuited a switch in a computer circuit.

The first bug was documented by Grace Hopper (first computer bug) , though the term bug goes back further than computers.


Grace Hopper is known for the saying that it is easier to ask forgiveness than to ask for permission.

The use of the word bug to describe a problem, however, was in use long before computers were invented.

Thomas Edison used the term "bug" to refer to a glitch, error, or defect in a mechanical system or process.

Edison: America's greatest inventor

• phonograph
• motion picture camera
• practical long-lasting light bulb

Shakespeare used the term "bug".

...The bug which you would fright me with, I seek. William Shakespeare, The Winter's Tale, III, 2

The word "bug" here means a frightful object, derived from a Welsh mythological monster called the "Bugbear".

In Windows, users sometimes encounter the BSOD (Blue Screen of Death) where the entire screen turns blue and a message is displayed. Often, the user ends up cold booting the computer.

Microsoft does not refer to bugs as bugs. Instead, the following terms are to be used by their support staff when talking to customers.

• an issue, such as a known issue or an intermittent issue
• design side-effect
• undocumented behavior
• technical glitch
• anomaly

This language has been christened "Microspeak", at least by James Gleick. Gleick, J. (September 1997). "A bug by any other name...", in Visual Basic programmer's journal, Vol 7, No. 10, p. 128..

James Gleick wrote the following.

• The Information: A history, a theory a flood (2011)
• Chaos: making a new science (1987)
• ... and many other books ...

The MSDN (Microsoft Developer Network) contains an ATS (Anomaly Tracking System) .

The word anomaly is used often in database terms to refer to an error in the database. It sounds so much better than calling it an error or bug.

Welcome to Anomaly Tracking System (ATS), the database application designed to track issues during team development of software.

Issues can be bugs in the code [i.e., your code], inconsistencies between the product and the specification, or future wish-list features.

How can you test a program to insure that it does not have any errors?

Program testing can be used to show the presence of bugs, but never to show their absence! 1972. Edsger Dijkstra (program testing) Dahl, O., Dijkstra, E., & Hoare, C. (1972). Structured programming. New York: Academic Press., p. 6. .

Dijkstra has said that if debugging is the process of removing bugs from a program, then programming must be the process of putting them in.

Here is the reasoning adapted from Dijkstra. Consider showing the correctness of a method for multiplying two numbers. The method is correct if, given two numbers, a correct result is always supplied. Let each number be represented by 32 bits. Then there are

2³² * 2³² = 2⁶⁴

possible ways to multiply the 2 numbers.

Smaller example to show method:

Let us also suppose that we have a table by which to check the results (this would be a big table). If we can check about 2³⁰ possibilities per second (a billion possibilities a second), it would take about 2³⁴ seconds to check all possible combinations. There are about 2²⁵ seconds in a year, so it would take 2⁹ years (about 500 years).

Now let each number be represented by 64 bits. Then there are

2⁶⁴ * 2⁶⁴ = 2¹²⁸

possible ways to multiply the 2 numbers.

Now the time is about this many years.

The hardware will fail before we can check even a tiny fraction of the possibilities. The same is true of software. The bottom line is that we buy computers that will only ever use a tiny fraction of all possible computations.

But we expect every one of them to be correct. Obviously we cannot check correctness by exhaustive enumeration.

As a result, testing can never show the correctness of a program, but it can show the presence of errors. There are, however, mathematical ways to prove certain programs correct.

Programs, to a large extent, can be verified to be correct using various program correctness techniques.

The field is called software verification.

In a beginning programming course, one need only know that such techniques exist and that programs cannot be shown or proven correct by testing.

Who uses formal verification of software?

Formal software verification is very costly to use but is used when the cost of failure is very high.

• NASA - space missions
• Chip manufacturers (Intel, AMD, etc.) - cost of failed processors (Pentium bug) are very high.
• Amazon - web and cloud services

Program testing is only useful for showing that a program appears to be good enough to use for some purpose.

A student can encounter such issues when a program works for them with some test data, but then does not work on another computer and/or with other test data.

As I have now said many times and written in many places: program testing can be quite effective for showing the presence of bugs, but is hopelessly inadequate for showing their absence. 1976. Edsger Dijkstra (program bugs) Dijkstra, E. (1976). A discipline of programming. Englewood Cliffs, NJ: Prentice-Hall., p. 20. .

Harry Truman was the President after Franklin Roosevelt and before Dwight Eisenhower.

He had a famous saying that "The buck stops here". That is, he would make the final decision.

It is the software engineer's job to insure that "the bug stops here", a play on words on the saying "the buck stops here", made famous by President Harry Truman.

Otherwise, program errors could have severe consequences (lost revenue, liability, death, etc.)

If you have software that is not working quite right, it may be due to a bug (or feature).

A web search might help you locate and fix the problem.

Identifying and resolving an error may be easy or it may be difficult.

• Error by the user (not anticipated)
• Error in the program (by the programmer: syntax, semantics, logical, etc.)
• Error in the compiler (by some other programmer) or programming language being used (feature)
• Error in the IDE (Integrated Development Environment)
• Error in the operating system
• Error in the hardware
• Error in how the system inter-operates (between any levels).

11 questions omitted (login required)

4 acronyms omitted (login required)