systematic-debugging

Root cause debugging involves systematically investigating error messages, reproducing the issue consistently, and gathering evidence before proposing fixes. This four-phase approach—root cause investigation, pattern analysis, hypothesis testing, and implementation—ensures you understand *why* a problem occurs, preventing wasted effort and new bugs from symptom-chasing.

Apply a scientific method: collect detailed data about when the failure occurs, identify differences between working and broken states, test single hypotheses with minimal changes, and validate each fix with evidence. This systematic troubleshooting prevents panic-driven fixes and ensures solutions address the actual problem, not just symptoms.

If multiple fixes fail to resolve the issue, the framework triggers an architectural review to evaluate whether the root cause lies in design rather than implementation. This prevents endless debugging cycles and identifies when a deeper structural change is needed.

Yes. The four-phase framework applies across test failures, production bugs, unexpected behavior, performance problems, build failures, and integration issues. The same evidence-based investigation and hypothesis-testing process works regardless of failure type.

Reproducibility and evidence are mandatory: document exact error messages, conditions that trigger the failure, differences between working and broken states, and dependencies involved. This data collection ensures your hypothesis is testable and prevents fixes based on incomplete information.