Debugging with the Scientific Method
summary
Argues that debugging follows the scientific method: form a cause (hypothesis), run small reproducible experiments, and treat the last successful experiment as the fix. Uses concrete tactics: make a minimal repro, do a bottom-up check (inner form first — e.g., the partial/join StackOverflow bug), prefer reproducible tests and logging, suspect GC/out‑of‑memory (Datomic + Cassandra vs H2), and automate where possible with tools like git bisect and the techniques in Why Programs Fail. Emphasizes writing everything down and shrinking the search space.
AI-written summary · about
chapters (34)
- 0:00Intro
- 1:09Why Debugging?
- 3:39Why Me?
- 6:04Why Clojure?
- 7:48Why Not Tools?
- 10:03Why Scientific Method?
- 10:30SM for Debugging
- 11:15Hypothesis
- 11:56Falsification
- 12:38Refinement
- 13:07Theory
- 18:10Actual Cause
- 19:34Why Is This Partial Not Working?
- 20:05What to Do?
- 21:48Hypotheses
- 22:25Bottom Up REPL Check
- 23:57Problem Statements
- 26:41Don't Sweat Naming
- 27:56Quick! Where's the Bug?
- 29:02Good Experiments
- 31:06Making Observations
- 32:23Unrelated?
- 33:58Write It Down
- 36:54The Failure is not the Defect
- 37:19Example: Is Hornet Broken?
- 38:40It's Always GC
- 41:06"Partial", Revisited
- 41:42What Would You Do Next?
- 42:32Test Cassandra vs. H2
- 43:13What We Learned
- 45:30Search Automation
- 46:06Call to Action
- 47:34Software Specifics
- 47:55Science Made Easy
related talks
20mDebugging: Techniques for Uncertain Times
35mThe Art of Troubleshooting
29mDebugging (with) your mind
47mWhen to give up, and how?
49mKeynote: Debug your thinking
26mSolving the problems in front of you
01h 09mPlenary: Coping With Other People's C++ Code
01h 08mFighting the controls: madness and tragedy for programmers