Generic or Specific? Making sensible software design decisions
summary
Argues that generic reuse always adds coupling and often costs far more than expected, even claiming reusable components are three times as costly to build and maintain; recommends the rule of three (extract after the third use) and iterating specific solutions first. Cites failed overly configurable data model that stalled a project and was replaced by a simple rebuild, and practical tools and patterns like JPA/Hibernate, Spring controller advice, OpenRewrite, monorepos and inner‑source for sharing code.
AI-written summary · about
chapters (17)
- 0:00Introduction and setup
- 1:10What is software design?
- 3:37Generic vs specific solutions
- 6:25Hierarchical decomposition
- 8:10Coupling and cohesion
- 10:59Locality and simplicity
- 13:28Future proofing and risk management
- 16:16Story of flexibility gone wrong
- 19:46Levels of generic decisions
- 23:41Tools to decide: YAGNI and five Ws
- 27:15Rule of three and strategic design
- 33:11Cost of generic solutions
- 37:46Bad reasons for generic solutions
- 41:21Levels of abstraction and standardization
- 42:04Code challenges intermission
- 47:20Sharing code at scale
- 50:30Summary and 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
33mFrom Enterprise Architecture to Software Design - Critical Thinking
56mDesigning in the World of Microservices
27m“Good Enough” Architecture Part 2
46mAchieving an evolutionary architecture through simplicity
57mCore Software Design Principles for Programmers