Generic or Specific? Making Sensible Software Design Decisions
summary
Practical decision rules and concrete costs: use the rule of three (only abstract on the third reuse), prefer simple, local code over early abstraction, and treat abstractions as non‑zero cost. Real failures include a flexible UI that caused 6,000 queries and three slow rebuilds, and an organization that ends up with three e‑learning systems because teams refuse to share. Consider C4 levels, coupling, a monorepo vs per‑repo tradeoff, inner‑source maintenance, and generic controller advice for cross‑cutting errors.
AI-written summary · about
chapters (14)
- 0:00Intro
- 0:34Outline
- 1:07What is software design?
- 1:53Design vs architecture
- 2:35Definitions
- 12:38Flexibility in software
- 15:44Levels of generic vs specific
- 18:33Tools to help decide
- 27:26The cost of a generic solution
- 31:40When & why to go generic
- 33:45Examples why specific often is faster
- 39:29Bonus: Sharing code in an organization
- 42:41Summary
- 44:17Outro
related talks
51mGeneric or Specific? Making Sensible Software Design Decisions
51mGeneric or Specific? Making sensible software design decisions
51mGeneric or Specific? Making sensible software design decisions 
25mThinking Architecturally
46mAchieving an evolutionary architecture through simplicity
27m“Good Enough” Architecture Part 2
47mHow To Build Future Proofed Applications
57mCore Software Design Principles for Programmers