Honest mistakes caused by shallow interpretation of SOLID
summary
Shows concrete failures from shallow SOLID use: a growing base class that becomes a god object, an engine example where adding an IEngine causes invalid regen throws, and a nullable loading flag that permits impossible UI states. Describes building a company glossary and platform‑agnostic architectural policies (favoring single source of truth, composition over inheritance, testability and clear ownership) used in design reviews and a deep‑links rewrite with marketing to remove assumptions, reduce confirmation bias, and catch trade‑offs before they reach production.
AI-written summary · about
chapters (13)
- 0:00Introduction to SOLID mistakes
- 1:10Trend-based decisions harm
- 3:38Design principles and patterns
- 7:07Base class anti-pattern
- 13:07Design patterns overview
- 15:57Domain vs presentation focus
- 18:07Google's architecture limitations
- 22:42Company glossary for clarity
- 24:47Stakeholder alignment matters
- 27:13Avoiding confirmation bias
- 29:58Skyscanner's architectural policies
- 32:46Practical policy examples
- 35:10Key learnings summary
related talks
01h 00mSOLID Revisited : The State of the Matter
39mSeveral years of SOLID-aware development
01h 19mSOLID Revisited: The State of the Matter
46mBe pragmatic, be SOLID
41mIs Your Code Too SOLID?
30mSOLID 101: A Review for Rubyists
01h 00mThe most dangerous phrase
01h 02mBasics Designs and How We Got Them Wrong