systematic-debugging

Systematic debugging follows four phases: Root Cause Investigation gathers evidence by reproducing the error and tracing data flow; Pattern Analysis identifies whether the issue is isolated or recurring; Hypothesis & Testing validates suspected causes through instrumentation; Implementation applies the fix after root cause confirmation. Complete all phases in order before proposing solutions.

Symptom patching masks underlying problems that resurface elsewhere. Root-cause debugging enforces explicit anti-shortcuts to resist rushed fixes under time pressure, requiring diagnostic instrumentation and phase-specific checklists to validate that the actual cause—not just the visible error—is addressed.

Root-cause investigation applies to test failures, build errors, and integration issues by tracing what conditions trigger the failure, whether the problem is deterministic or intermittent, and whether it stems from code, environment, or dependencies. Phase 1 reproduces and gathers evidence; later phases isolate and validate the true cause.

Performance debugging uses the same four-phase process: observe and reproduce the degradation, analyze whether it's consistent or context-dependent, form and test hypotheses about bottlenecks using diagnostic instrumentation, then implement fixes only after confirming the root cause rather than applying generic optimizations.

Root-cause debugging includes defense-in-depth validation: after identifying and implementing the fix in Phase 4, re-run diagnostics to confirm the original problem is resolved, check that the fix doesn't introduce side effects, and verify the behavior matches the expected outcome across all scenarios that triggered the bug.

Yes. The systematic approach is designed specifically for high-pressure debugging. Explicit rules resist the urge to patch quickly; following all four phases prevents wasted time on failed temporary fixes and ensures the actual cause is found, reducing total resolution time and preventing recurring issues.