systematic-debugging

Root-cause debugging requires a disciplined four-phase process: Root Cause Investigation, Pattern Analysis, Hypothesis & Testing, and Implementation. This systematic approach traces issues deep in the call stack before applying fixes, eliminating symptom-driven work and reducing rework.

Debugging multi-component systems works best with a phase-driven workflow that enforces explicit stop rules. By reproducing and tracing the problem during Root Cause Investigation before attempting any fix, you prevent shortcut fixes across deep call stacks.

To stop guessing during debugging, follow a systematic process with strict guardrails like NEVER fix the symptom and STOP and re-analyze. This forces thorough pattern analysis and hypothesis testing before implementation, replacing guesswork with structured investigation.

Systematic debugging is specifically applicable across software projects and multi-component systems where issues appear deep in the call stack. Its four-phase approach with defense-in-depth policies adds validation at multiple layers to trace and resolve deep-stack problems.

You should STOP and re-analyze whenever you find yourself attempting a shortcut fix or treating a symptom. This guardrail enforces a return to root cause investigation, ensuring your hypothesis testing phase validates the actual underlying problem before implementation.

Symptom-driven debugging leads to rework because it bypasses root cause investigation, pattern analysis, and hypothesis testing. Without a disciplined four-phase process with guardrails, fixes fail to address issues deep in the call stack, causing recurring problems in multi-component systems.