Mental Models for Software Engineers: The 20 Models That Explain 80% of Decisions
The Hook
You’re designing a system. You could analyze from first principles every time. Or you could use mental models — compressed heuristics that capture hard-won wisdom. The top 20 models explain 80% of architectural decisions. Here’s your reference card.
The Thesis
Mental models are compressed experience. They’re not rules — they’re lenses. The best engineers don’t know more facts; they have better models. These 20 models cover distributed systems, architecture, team dynamics, and technical strategy. Keep this page bookmarked.
The 20 Models
1. Amdahl’s Law — The Speedup Ceiling
Formula: Speedup = 1 / ((1 - P) + P/N) where P = parallelizable portion, N = processors
Lesson: Optimizing the non-parallelizable part (serial bottleneck) matters more than adding processors. Optimize the critical path first.
2. CAP Theorem — The Distributed Trade-off
Pick two: Consistency, Availability, Partition Tolerance Lesson: In a partition, you must choose C or A. Design for partition tolerance; choose C or A per use case.
3. Little’s Law — The Queue Formula
Formula: L = λ × W (Avg items in system = arrival rate × avg wait time)
Lesson: To reduce latency (W), reduce queue length (L) or arrival rate (λ). Queue depth = latency × throughput.
4. Conway’s Law — Org = Architecture
Law: “Organizations design systems that mirror their communication structures.” Lesson: If you want microservices, organize as small autonomous teams. Team topology dictates system topology.
5. Gall’s Law — Evolution Not Design
Law: “A complex system that works evolved from a simple system that worked.” Lesson: Don’t design complex systems from scratch. Start simple, evolve, never rewrite from scratch.
6. Chesterton’s Fence — Respect Existing Code
Principle: “Don’t remove a fence until you know why it was built.” Lesson: Before refactoring legacy code, understand why it’s that way. Assume competence; investigate before removing.
7. Parkinson’s Law — Work Expands
Law: “Work expands to fill the time available.” Lesson: Set aggressive but realistic deadlines. Time-box everything; scope expands to fill slack.
8. Brooks’s Law — Adding People Slows Down
Law: “Adding manpower to a late software project makes it later.” Lesson: Communication overhead = n(n-1)/2. Add people early or not at all; never late.
9. The Pareto Principle (80/20) — Focus on the Vital Few
Law: 80% of effects come from 20% of causes. Lesson: 20% of code causes 80% of bugs. 20% of features deliver 80% of value. Measure, find the 20%, ignore the rest.
10. Occam’s Razor — Simplicity Wins
Principle: Among competing hypotheses, the simplest is usually correct. Lesson: Prefer simpler architectures, fewer dependencies, fewer moving parts. Complexity is a liability; justify every part.
11. The Law of Leaky Abstractions (Spolsky)
Law: “All non-trivial abstractions, to some degree, are leaky.” Lesson: You cannot fully hide complexity. Understand the layer below; design for leakiness.
12. The Two-Pizza Rule (Bezos)
Rule: Teams should be small enough to feed with two pizzas (6-8 people). Lesson: Large teams = communication overhead. Keep teams small; prefer many small teams over one large.
13. The Peter Principle — Promote to Incompetence
Law: People rise to their level of incompetence. Lesson: Promote based on current role performance, not next role potential. Create dual-track careers (IC + management).
13. The Bus Factor — Knowledge Distribution
Metric: How many people can be hit by a bus before the project stalls? Target: Bus factor ≥ 3 for critical systems. Document, pair, rotate; no single points of failure.
14. Hyrum’s Law — Interface Contracts
Law: “With enough users, all observable behaviors become dependencies.” Lesson: Don’t rely on undocumented behavior. Version APIs; communicate changes; deprecate slowly.
15. The Rule of Three (Refactoring)
Rule: First time: do it. Second time: wince. Third time: refactor. Lesson: Premature abstraction is waste. Wait for the pattern; then extract.
16. YAGNI (You Aren’t Gonna Need It)
Principle: Don’t add functionality until you need it. Lesson: Every feature adds maintenance burden. Build for today; design for tomorrow; implement only today.
17. DRY vs. WET — Duplication vs. Coupling
DRY: Don’t Repeat Yourself. WET: Write Everything Twice. Lesson: DRY creates coupling; WET creates duplication. Prefer duplication over premature abstraction; refactor when pattern is clear.
18. The Iron Triangle — Scope, Time, Resources
Triangle: Pick two — Scope, Time, Resources (Quality is the area). Lesson: You cannot fix all three. Explicitly choose which two; communicate the third as variable.
19. The Boy Scout Rule — Leave It Better
Rule: Always leave code better than you found it. Lesson: Small improvements compound. Fix one thing every touch; technical debt paid in installments.
20. The Map Is Not the Territory (Korzybski)
Principle: Models are not reality; they’re useful approximations. Lesson: Metrics ≠ reality; diagrams ≠ system; plans ≠ execution. Validate assumptions in production; trust data over models.
Quick Reference Card
| Decision Context | Apply These Models |
|---|---|
| Performance tuning | Amdahl’s Law, Little’s Law, Pareto |
| Architecture design | CAP, Conway’s Law, Gall’s Law, Leaky Abstractions |
| Team scaling | Two-Pizza Rule, Brooks’s Law, Peter Principle, Bus Factor |
| Refactoring | Chesterton’s Fence, Rule of Three, YAGNI, Boy Scout Rule |
| Project planning | Parkinson’s Law, Iron Triangle, Pareto |
| API design | Hyrum’s Law, Leaky Abstractions, Occam’s Razor |
| Debugging | Occam’s Razor, Chesterton’s Fence, Pareto |
| Career decisions | Peter Principle, Two-Pizza Rule, Bus Factor |
How to Use This
- Bookmark this page — reference before major decisions
- Teach your team — shared vocabulary = faster alignment
- Apply one per week — deep-dive one model per sprint retro
- Build your own list — add domain-specific models
Sources & Further Reading
- Amdahl (1967) Validity of the Single Processor Approach
- Brewer (2000) Towards Robust Distributed Systems (CAP)
- Little (1961) A Proof for the Queuing Formula
- Conway (1968) How Do Committees Invent?
- Gall (1975) Systemantics
- Spolsky (2002) The Law of Leaky Abstractions
- Brooks (1975) The Mythical Man-Month
- Bezos (1997) Amazon Shareholder Letters
- Northcote & Parkinson (1957) Parkinson’s Law
- Hyrum Wright (Google) Hyrum’s Law