How to stop breaking other people's things
summary
Defines a breaking change as any API change that makes an integrator’s assumption false and gives concrete examples: changing an error response string, splitting a database transaction so events can be missing, shifting daily batch timing, or reducing latency that suddenly spikes webhook-driven load. Recommends measurable practices: document edge cases, make behavior discoverable, use semantic versioning where possible, roll out by percentage, test in sandboxes, add observability and keep a kill switch ready.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 0:36A sad story
- 1:19Investigating
- 3:26Examples
- 9:13Breaking changes
- 10:10Explicit assumptions
- 11:17Implicit assumptions
- 12:47Observer behaviour
- 14:24MS DOS example
- 15:42Unconscious assumptions
- 16:37Discoverability
- 16:58Consistency
- 18:14Naming
- 20:09A change isnt breaking
- 20:52Not all breaking changes are equal
- 22:11Identify which integrators to reach out to
- 22:21Semantic versioning
- 23:37Overcommunicating
- 25:20Mitigation
- 26:30Managing risk
- 27:45Outro
related talks
30mBreaking changes in Design system
30mBreaking backwards compatibility: The easy way!
01h 01mContinuous Integration: I Invite You to Break My Build
26mHow to Break an API: How Community Values Influence Practices
44mBackwards Incompatible Tales
22mFear of the computer
27mDevOps Patterns and Antipatterns for Continuous Software Updates
32mHow to Not Break Your GraphQL Clients