A software bug is an error, flaw, or fault in a program’s code that makes it produce an incorrect or unexpected result, or behave in unintended ways. Bugs range from the trivial, such as a misplaced label, to the catastrophic, such as a flight-control miscalculation that destroys a rocket. Because nearly all non-trivial software contains them, much of the discipline of software engineering is organized around finding, classifying, and preventing bugs rather than pretending they can be eliminated entirely.
The word itself is older than the computer. Engineers, including Thomas Edison, used “bug” to mean a defect or glitch for decades before electronic computing. The most famous artifact connecting the term to computing is preserved at the Smithsonian’s National Museum of American History: a 1947 logbook page from the Harvard Mark II with an actual moth taped to it and the note “First actual case of bug being found.” As the existing record of that artifact makes clear, the note is a joke on existing slang, not the coinage of the word. The Smithsonian object record documents the logbook page directly.
Bugs come in recognizable classes, and naming them is the first step toward defending against them. A regression is a previously working feature that breaks after a change. A race condition is a fault whose appearance depends on the uncontrolled timing of concurrent operations. An off-by-one error is a miscount at the boundary of a loop or array. A null-pointer dereference is an access through a reference that points at nothing. Each class has its own symptoms, its own tools, and its own preventive techniques.
A central observation of software engineering is the cost curve: the expense of fixing a bug rises sharply the later it is caught. A defect found while a developer is still typing costs almost nothing; the same defect found in production, after it has corrupted data or harmed users, can cost orders of magnitude more. This asymmetry is the economic argument behind code review, automated testing, and continuous integration, all of which aim to move detection earlier.
It is worth distinguishing a bug from a failure. A bug is the latent fault in the code; a failure is the observable misbehavior when that fault is exercised by some input or timing. Many bugs lie dormant for years because the conditions that trigger them are rare. This gap is why testing can demonstrate the presence of bugs but, as a famous remark holds, never their absence: a passing test exercises only the paths it happens to cover.
The enduring lesson is that bugs are normal, not exceptional. Mature practice treats them as a managed quantity, with conventions for reporting, reproducing, classifying, and tracing each one back to its cause, rather than as embarrassing surprises to be hidden.