Generic or Specific? Making sensible software design decisions
summary
Argument: every generic solution introduces coupling and costs more to build and maintain — reuse is three times as difficult and often three times as expensive. Practical rules: apply rule of three (only abstract on the third reuse), ask YAGNI and the five W’s, use strategic design for core/support/generic subdomains, and prefer inner‑source, versioning and clear lifecycle rules for shared libraries. Real failures include a configurable system that issues a 6,000 lines of SQL query and a six‑second page load, proving premature genericity backfires.
AI-written summary · about
chapters (14)
- 0:00Introduction and setup
- 3:21What is software design?
- 7:32Hierarchical decomposition and coupling
- 13:11Cost of generic solutions and DRY
- 21:42Government project failure case study
- 25:59Abstractions and their costs
- 27:04Tools to decide: YAGNI and five Ws
- 30:16Rule of three and strategic design
- 34:07Conway's law and organizational impact
- 37:37When to go generic: valid reasons
- 41:07Why specific solutions are faster
- 44:15Generic vs specific: exception handling example
- 45:39Sharing code in organizations
- 48:57Conclusion and final advice
related talks
51mGeneric or Specific? Making sensible software design decisions 
45mGeneric or Specific? Making Sensible Software Design Decisions
51mGeneric or Specific? Making Sensible Software Design Decisions
56mDesigning in the World of Microservices
27m“Good Enough” Architecture Part 2
25mBuilding Applications in the Cloud
46mAchieving an evolutionary architecture through simplicity
57mCore Software Design Principles for Programmers