Is Your Code Too SOLID?
summary
Argues that SOLID is a mixed bag — SRP has medium utility, O and L are low utility, I and D are high utility — and that patterns alone don’t tell you when to apply them. Recommends tactical habits: avoid week‑long “stop the world” refactors, add integration tests one level above the unit under change, prefer tiny, local fixes that reveal real abstractions, be willing to roll code back into procedures to regroup, and resist premature microservice splits until object boundaries emerge.
AI-written summary · about
chapters (11)
- 0:00Introduction and background
- 3:59Technical debt and business trade-offs
- 7:29Refactoring vs microservices
- 10:48Software design definitions
- 12:52Cost of understanding vs changing code
- 17:05SOLID principles explained
- 24:42Design patterns and their limits
- 27:31Strategy vs tactics in code design
- 31:23Stop-the-world refactoring pitfalls
- 34:12STABLE tactics for refactoring
- 39:40Q&A
related talks
01h 00mSOLID Revisited : The State of the Matter
46mBe pragmatic, be SOLID
01h 00mThe most dangerous phrase
57mCore Software Design Principles for Programmers
01h 19mSOLID Revisited: The State of the Matter
28mSOLID Go Design
37mHonest mistakes caused by shallow interpretation of SOLID
30mSOLID 101: A Review for Rubyists