after we build · part three
Bugs and Their Roots
Every defect traces to a level of the chain. Six dimensions classify it. Finding which level produced it is more important than fixing the symptom — because the symptom will recur if the level stays broken.
Bug filing whenever someone reports something behaving wrong. Triage is short, daily, inside the standup; correct labels, not debate. Root cause named after the fix, not before.
This is where meaning's gaps become visible. A bug is not a failure of code. It is evidence of where the chain failed to preserve meaning. Every bug has two stories: what broke, and which level of the chain should have caught it. Skipping the second story is how the same bug recurs in a different form — wearing a different name, filed by a different person, costing twice as much.
Defects and bugs — the same taxonomy, different timing
A defect is found before production — during development, QA, or staging. It is filed as a sub-task of the story that produced it. A bug is found in production — by a user, by CS, by monitoring. It is filed as an independent issue with the full taxonomy.
The classification system is the same for both. The difference is timing: defects are cheap to fix (the code is still being worked on); bugs are expensive (the code has shipped, the user has been affected, trust has been spent). The taxonomy exists to make both traceable — and to make the pattern of where defects and bugs cluster visible over time.
The two-question rule
When filing a defect or bug, two questions are answered first. Everything else follows.
- How technically bad is it? — that is Severity. About the code: data loss, security breach, broken core flow, cosmetic glitch.
- How badly does it affect users? — that is Impact. About the experience: blocked, severely degraded, inconvenient, barely noticeable.
These are not the same thing. A critical security flaw in a feature used by three admins is high severity but medium impact. A misaligned button that blocks the primary call-to-action is low severity but blocker impact.
Collapsing them into a single "priority" field is how the most consequential decision in triage gets argued about for the rest of the project.
Continue — Severity × Impact and the four other dimensions →