Root Cause Analysis
Escalating past the visible symptom until you find the layer that actually produced it.
Root cause analysis is the discipline of continuing to investigate a fault past the first plausible explanation, until you reach the layer that actually produced it. Its practical test is simple: if a fix does not fully clear the symptom, that is evidence you have not found the cause yet — not an invitation to add a second patch beside the first.
The failure mode it guards against is the patch stack: three defensive changes at three different layers, each of which addressed something real but none of which was the cause. Stacked patches are expensive twice over. They cost the round trips it took to write them, and they leave behind code whose purpose nobody can reconstruct — a future reader cannot tell a real constraint from a superstition. See Chesterton's Fence for the other half of that problem.
Root cause work depends on Ground Truth. A hypothesis about a cause is worth exactly as much as the observation behind it, so the move is usually to go get one measurement — the computed style, the network request, the actual bytes on disk — rather than to reason forward from what the code appears to say. Observability is what makes that measurement cheap.
The same instinct applies one level up. When a fix introduces a Regression, the interesting question is not "what broke" but "what about the way I fixed it made this breakable". Fixing the substrate rather than the symptom is what keeps Technical Debt from compounding.
See also4
Hand-picked in the note itself — the neighbours worth reading next.
Falsifiability
A claim is only worth something if you know what observation would refute it.
Method16 connections
Reproducible Case
The smallest set of steps that reliably produces a fault, and the unit of real debugging.
Method17 connections
Silent Failure
A failure that produces no signal, so the absence of an error reads as success.
Method44 connections
Plausible Mechanism
A causal explanation that was inferred rather than tested, and reads as more rigorous for being specific.
Method19 connections
Linked from20
Notes elsewhere in the wiki that reach for this one.
- Anchoring EffectMethod
A stated number pulls subsequent estimates toward it, regardless of relevance.
- CascadeDesign & Interface
The algorithm deciding which declaration wins when several apply to the same element.
- Chesterton's FenceMethod
Do not remove something whose purpose you cannot explain.
- CronSystems & Tooling
Time-based scheduling of recurring jobs, and the reasons scheduled jobs quietly stop working.
- CSS Custom PropertyDesign & Interface
A user-defined CSS property that participates in the cascade and inherits down the tree.
- DaemonSystems & Tooling
A long-running background process managed by the operating system's service supervisor.
- DeprecationMethod
Marking something as superseded and scheduled for removal, without removing it yet.
- Design TokenDesign & Interface
Named design decisions — colour, spacing, radius, type — stored as data so they can be shared and re-themed.
- Exhaustive ClaimMethod
A statement of the form "the last one" or "nothing else does this" — load-bearing, and only as good as the search behind it.
- FalsifiabilityMethod
A claim is only worth something if you know what observation would refute it.
- GlobSystems & Tooling
Wildcard pattern matching over filenames, similar enough to regular expressions to mislead.
- Ground TruthMethod
The measurement that arbitrates, as opposed to the artifact that merely reports.
- ObservabilityMethod
How much of a system's internal state can be inferred from what it emits.
- RegressionMethod
A previously working behaviour that a change has broken.
- Reproducible CaseMethod
The smallest set of steps that reliably produces a fault, and the unit of real debugging.
- Scoped StylingDesign & Interface
Confining a set of style decisions to a subtree so the same component can look different in different contexts.
- Silent FailureMethod
A failure that produces no signal, so the absence of an error reads as success.
- Technical DebtMethod
The future cost of a present shortcut, metaphorically accruing interest.
- Test-Driven DevelopmentTesting & Verification
Writing a failing test first, making it pass, then improving the code with the test as a net.
- Truncation BiasMethod
Reading a truncated result as if it were the whole result, so every counterexample is invisible.