Learning to Live with Errors
summary
Argues that no single method solves real-world errors and recommends mixing approaches: use TDD: failing tests as spec to drive development, use dependent types (Idris, F) or formal verification for high-assurance code (cryptography), and design fault-tolerant systems with let it crash supervision* à la Erlang so processes restart automatically. Cites concrete failures: a language model mistranslates political names from web training data, a trading firm loses ~$400M from a stale-version flag, and Y2K relied on people on-call to patch live systems.
AI-written summary · about
chapters (4)
- 0:00Start
- 11:24Tests become the specification Tests as a honest documentation
- 21:48Errors as the unavoidable Erlang error is the opposite of test error Errors are the lack of specification They are expected - are they still errors?
- 35:08Prove or test properties Identifying properties is the hard problem Fix the system by hand Needs to be designed for manual intervention
related talks
44mA Practical Approach to Error Handling
22mResilience Is Not Enough
44mA Practical Approach to Error Handling
45mThe design of error
36mDesigning for failure - architecting fault-tolerant system
42mWhat our Brains can Teach us About Software Engineering
24mHow to solve intermittent issues, aka Random Failures
54mThe Error of our Ways