investigate

Root cause analysis of a stack trace requires collecting symptoms, reading relevant code paths, and checking recent changes to iteratively narrow causes until validated. You gather evidence through structured phases before hypothesizing, ensuring no fixes are planned without identifying the underlying cause.

Systematic debugging stops whack-a-mole patching by enforcing a root-cause-first discipline. By running a structured investigation workflow across investigate, analyze, hypothesize, and implement phases, you validate the underlying cause before applying fixes, which eliminates repeated regressions.

Error triage and fix planning require an evidence-driven approach where you collect symptoms and read the failing code paths first. After conducting systematic root-cause investigation, you can plan fixes based on validated hypotheses rather than guessing.

Regression hunting is a best-fit scenario for this approach. When something breaks only after recent changes, the investigation workflow checks those modifications, collects the new symptoms, and traces the relevant code paths to isolate and validate the exact cause of the unexpected behavior.

Fixing symptoms without root cause analysis leads to repeated regressions because the underlying fault remains active. The investigation workflow enforces the principle of no fixes without root cause, requiring evidence-driven hypotheses to be validated before implementation.

To start investigating a software failure, you need the observed symptoms, such as error messages or stack traces, and access to the relevant code paths. The investigation begins by collecting these symptoms and checking recent changes to form evidence-driven hypotheses.