Fix

Origin & evolution

The vocabulary of mitigation, workaround, and permanent fix was formalised by IT service management. ITIL splits the work into incident management, whose job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is to restore service fast, often via a workaround, and problem management, whose job is to find and remove the underlying cause. A workaround is an accepted, documented holding pattern; the permanent fix is the change that retires the problem record. The split exists because the two have different urgencies: a customer-facing outage needs🫀NeedUserA user need, pain, desire, or constraintView reference → restoration in minutes, while the structural repair can take a careful week.

Software engineering added a discipline of its own: a regression test♻️Regression TestQuality AssuranceA regression testView reference → for every fix. When a bug🐛BugProduct SpecificationA defect or unexpected behaviourView reference → is found, you first write a failing test that reproduces it, then make the test pass, so the same defect cannot return unnoticed. Martin Fowler describes this as the natural response to a bug in his writing on self-testing code: a defect that escaped means a test was missing, so the fix includes the test that should have caught it.

Mature teams ship the workaround under incident pressure, then return for the permanent fix when the diagnosis is solid, and they distrust any fix that arrives without a test proving what it repaired.

How it works in practice

A search service starts timing out under load. The on-call engineer applies a mitigation at 21:40: route traffic away from the degraded node, which restores service within four minutes. That is a workaround, and the incident is downgraded. The investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference → then traces the timeout to an unbounded cache that grew until garbage collection stalled the process. The permanent fix caps the cache and adds an eviction policy. To close the loop, the engineer adds a load test that fills the cache past the old limit and asserts latency stays flat. Without that test, the next refactor could quietly reintroduce the unbounded growth and nobody would know until the pager fired again.

Fix vs. its neighbours

• Bug is the defect in the code or configuration; the fix is the change that removes it. The bug🐛BugProduct SpecificationA defect or unexpected behaviourView reference → describes what is wrong; the fix describes what was done about it. A fix can resolve several bugs, and one stubborn bug can take several attempted fixes.
• Root cause🪝Root CauseEngineeringAn identified root cause of an issueView reference → is the underlying condition, which may be organisational, not just a line of code. A permanent fix targets the root_cause🪝Root CauseEngineeringAn identified root cause of an issueView reference →; a workaround targets only the symptom. The difference is whether the fault can recur.
• Investigation is the diagnosis that tells the fix where to aim. A fix shipped without an investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference → is a guess, and the regression-test discipline is what converts a guess into a verified repair.

In the graph

In the Unified Product Graph, fix🪛FixEngineeringA fix applied to resolve an issue sits in the engineering and reliability region as the resolution node of an incident chain. It closes work through fix_resolved_bugFixresolvedBugcausal and fix_resolved_root_causeFixresolvedRoot Causecausal, with the reciprocal root_cause_resolved_by_fixRoot Causeresolved byFixcausal recording the same closure from the cause's side. Its provenance is captured by fix_derived_from_investigationFixderived fromInvestigationcausal, which ties the change back to the diagnosis that justified it. Separating the fix from the bug and the root cause lets the graph distinguish a workaround that touched only a symptom from a permanent fix that resolved the underlying root_cause🪝Root CauseEngineeringAn identified root cause of an issueView reference →, so a closed incident can be audited for whether it actually ended.