systematic-debugginglisted

# Systematic Debugging ## Contents - [Overview](#overview) - [Iron Law](#iron-law) - [Where It Applies](#where-it-applies) - [The 4 Phases](#the-4-phases) - [Phase 1: Root-Cause Investigation](#phase-1-root-cause-investigation) - [Phase 2: Pattern Analysis](#phase-2-pattern-analysis) - [Phase 3: Hypothesis and Test](#phase-3-hypothesis-and-test) - [Phase 4: Implementation](#phase-4-implementation) - [Red Flags. Stop and Return to the Procedure.](#red-flags-stop-and-return-to-the-procedure) - [Signs the User Thinks You Are Going Wrong](#signs-the-user-thinks-you-are-going-wrong) - [Common Rationalizations](#common-rationalizations) - [Quick Reference](#quick-reference) - [When the Procedure Reveals "No Root Cause"](#when-the-procedure-reveals-no-root-cause) - [Supporting Techniques](#supporting-techniques) ## Overview Random fixes waste time and create new bugs. A quick patch hides the root problem. ○ Core principles - Always find the root cause before fixing. A symptom-only fix is a failure. - Breaking the letter of this procedure is breaking the spirit of debugging. ## Iron Law ``` Do not attempt a fix before finishing the root-cause investigation. ``` If you have not finished Phase 1, you cannot propose a fix. ## Where It Applies Apply it to every technical issue. - Test failures - Production bugs - Unexpected behavior - Performance problems - Build failures - Integration issues □ Situations where it especially must be applied - Under time pressure (th