fail-fast-debugging

Root-cause debugging requires pausing before coding changes. Follow the four-phase process: observe the exact error and stack trace, reproduce it consistently, trace execution to find where it fails, then hypothesize the cause. Only after verifying your hypothesis should you fix code. This prevents quick patches and technical debt.

Quick Fix, Shotgun Debugging, Retry Logic, Hope-Based Debugging, and Blame Shifting are documented anti-patterns that mask root causes. Quick fixes create debt; Shotgun Debugging wastes time on unrelated code; Retry Logic hides failures; Hope-Based Debugging skips investigation; Blame Shifting delays resolution. Enforce mandatory root-cause investigation instead.

Apply the four-phase debugging workflow across all failure modes: observe the exact error, reproduce it consistently, trace code execution paths, and form a hypothesis about the root cause. Verify your hypothesis before coding. This discipline works for timeouts, permission issues, infinite loops, crashes, and other failures.

The 2-Attempt Rule caps exploratory changes at two tries. If an approach fails twice, stop and diagnose the root cause rather than patching incrementally. This prevents rabbit holes and forces deeper investigation into why your approach isn't working, leading to better fixes.

Enforce one-change-at-a-time discipline and verification before completion. Require developers to document the four phases—Observe, Reproduce, Trace, Hypothesize, Verify—before proposing fixes. This keeps velocity high by preventing cascading bugs from unverified changes and reduces technical debt.

Yes. Fail-fast debugging is designed for pre-launch phases to keep velocity high and technical debt low. Enforcing root-cause investigation before fixes discourages quick patches and resilience patterns that hide problems, resulting in cleaner code and faster resolution of actual issues.