Backwards Incompatible Tales
summary
Shows why seemingly small API or type changes break real systems: MCAS-related 737 MAX crashes as a documentation/BC-failure example, PHP’s namespace and RFC-variance pitfalls, Doctrine/Symfony breakage chains, and hidden serialization and iteration behaviors that silently break downstream code. Recommends automated checks (use Roave Backwards Compatibility Check in CI), strict semantic versioning, exhaustive tests, deprecation cycles, and operational rules like don't deploy on Fridays so breaks get reasoned, announced, and reversible.
AI-written summary · about
chapters (14)
- 0:00Start
- 3:08CHANGE IN REQUIREMENTS
- 3:49SYSTEM CHANGES
- 8:21CHANGE IN SYSTEM ASSUMPTIONS/REQUIREMENTS
- 9:29PHP OBJECT ORIENTED PROGRAMMING
- 9:47CHANGES IN TYPES
- 20:29MORE QUIZ TIME!
- 23:19DOES TYPE X FIT INTO TYPE Y?
- 24:23MAKE THINGS "FINAL"
- 24:33MAKE THINGS "@INTERNAL"
- 30:18TEST CHANGES?
- 33:03SECURITY RELEASES ARE NECESSITY
- 33:22BROKEN SYSTEM BETTER THAN COMPROMISED SYSTEM
- 34:23CONSIDER DEPRECATING THINGS FIRST
related talks
01h 01mGuide to Destroying Codebases the Demise of Clever Code
49mBackward Compatibility in the Java World
50mTactics and strategies on software development: how to reach ...
41mTesting Legacy Code & Safe Refactoring
39mSeveral years of SOLID-aware development
32mEscaping Version Skew: Formalizing Compatibility in a World of Partial Rollouts
21m50 Shades of Legacy
35mRedundancy Driven Development - Navigating disruptive codebase changes.