Bug

Origin & evolution

The term is older than computing. Thomas Edison used "bug" for technical faults in his inventions; an 1878 letter refers to "'Bugs', as such little faults and difficulties are called". The famous 1947 incident🚨IncidentDevOps & PlatformA production incidentView reference →, in which a moth was found taped into the log book of Harvard's Mark II relay computer with the note "first actual case of a bug being found", is real, and Grace Hopper's team helped popularise the word in computing. The historian Fred Shapiro has shown the moth was a joke playing on an already-current term, not the origin of it.

What changed over the following decades was not the word but the rigour around it. The IEEE eventually separated the vocabulary: a fault is the latent flaw in the code, an error is the incorrect internal state it produces, and a failure is the observable wrong behaviour a user sees. "Bug" in common usage spans all three, which is why disciplined teams attach a severity and a reproduction path to pin down which they mean.

The economics of bugs drove the next shift. Studies popularised through Barry Boehm's work argued that defects grow more expensive to fix the later they are caught, which pushed testing earlier (the "shift left" movement) and made the goal preventing bugs at the point of writing rather than only catching them at the end.

How it works in practice

A user reports that exporting a report as PDF produces a blank file. The team files a bug with a severity of high (data loss, no workaround) and a clear repro: export any report over 50 pages on the web app, in Safari, and the file is empty. The bug points at the export feature⭐FeatureProduct SpecificationA product capability or featureView reference → it affects, which scopes the investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference → to one code path rather than the whole app.

A fix lands and the patch ships as release🚢ReleaseProduct SpecificationA shipped version of the productView reference → 3.1.2, the patch bump signalling a backward-compatible correction. The bug is marked resolved, and a regression test♻️Regression TestQuality AssuranceA regression testView reference → is added so the same break cannot return silently. Because the bug recorded its repro and its severity up front, the team could triage it against other work honestly, and the link to the affected feature meant the right engineer picked it up without a hunt.

Bug vs. its neighbours

• Feature request🙏Feature RequestCustomer FeedbackA user-submitted feature requestView reference → asks for new behaviour the product was never meant to have. A bug reports existing behaviour failing to match what it was meant to do. The line is intent: a request widens the spec, a bug enforces it.
• Task☑️TaskProduct SpecificationA unit of work within a story or epicView reference → is a planned unit of work the team chose to do. A bug is unplanned, surfaced by the gap between intent and reality. Both become work, but a backlog full of bugs and a backlog full of tasks tell very different stories about a product's health.
• Acceptance criterion✅Acceptance CriterionProduct SpecificationA condition that must be met for a story to be doneView reference → is the condition that defines correct behaviour in advance. A bug is what you call a violation of that condition discovered after the fact. The criterion is the contract; the bug is the breach.

In the graph

In the Unified Product Graph, bug🐛BugProduct SpecificationA defect or unexpected behaviour is a leaf in the Product and Delivery region. It connects upward and outward by what it damages: bug_affects_featureBugaffectsFeaturecross-domain ties it to the feature whose behaviour broke, and bug_affects_serviceBugaffectsServicecross-domain (a cross-domain edge into the Engineering region) ties it to the underlying service when the fault is infrastructural. The same defect can carry both edges at once. Keeping a bug as a first-class node with explicit "affects" edges is what lets the graph answer which features are currently degraded and which services are implicated, turning a flat bug list into a map of where the product is not behaving as designed.