Glossary
The vocabulary, no jargon
The book’s key technical terms, explained simply.
- SSoT (single source of truth)
- One piece of data is authoritative. We avoid duplicating information across systems that eventually diverge.
- The book’s principle: Single source of truth →
- SoC (Separation of Concerns)
- Separating responsibilities: each module does one thing well, without stepping on the others.
- The book’s principle: Separate concerns →
- Technical debt
- The future cost of shortcuts taken today. Distinguish suffered debt (you absorb it) from chosen debt (you steer it).
- The book’s principle: Acknowledge inherited debt and tame chosen debt →
- Library-first
- Design a reusable library first, then the application around it. Favors reuse and clean interfaces.
- The book’s principle: Favor a library-first approach →
- Human map/reduce
- Distribute work across people (map) then consolidate (reduce). Powerful but costly in coordination: use sparingly.
- The book’s principle: Use human map/reduce sparingly →
- Go for the edge
- Tackle edge cases early. They reveal the real design problems.
- Conway’s law (inverse)
- A system’s architecture mirrors the organization that builds it. Inverting it means structuring teams to get the architecture you want.
- The book’s principle: Scale teams by following the inverse Conway’s law →
- UAT (User Acceptance Testing)
- User acceptance environment. In the book: if you need one, it’s often a sign of a poorly designed product.
- The book’s principle: If you have a UAT environment, you’ve failed your product →
- Monitoring & alerting
- Measure the system’s state (monitoring) and get notified when it goes wrong (alerting). One without the other is useless.
- The book’s principle: No monitoring without alerting →
- Declarative vs imperative
- Describe the desired result (declarative) rather than the sequence of steps (imperative). More readable, more robust.
- The book’s principle: Prefer declarative over imperative →