first-principles

First Principles Thinking for Software Development

Overview

Decompose problems to fundamental, verifiable truths and rebuild solutions from those — instead of reasoning by analogy ("how does X do it?", "what's the best practice?"). Produces solutions grounded in actual requirements, not convention.

The core lens (Brooks): every system carries essential complexity (inherent to the problem) and accidental complexity (introduced by tools, conventions, and copied patterns). First-principles thinking strips the accidental away. See references.md for No Silver Bullet and Out of the Tar Pit.

When to Use

Situation	Workflow
Architecture / tech stack / framework choice	Full 7 steps
Complex bug resisting conventional fixes	Full 7 steps
Performance past surface caching	Full 7 steps
Questioning a pattern or abstraction	Full 7 steps
Two-way-door decision (reversible in <1 day)	Lite version (see below)
Routine implementation with clear requirements	Skip — just build
Time-critical hotfix	Skip — patch now, post-mortem later

Bezos filter (one-way vs two-way doors): reversible decisions don't deserve the full ceremony. Irreversible ones — database choice, public API shape, primary language, data model — do.

Quick Reference

#	Action	Key Question	Framework
1	DEFINE	What am I actually trying to achieve?	—
2	SURFACE	What am I assuming, and why?	Socratic Questioning (6 types)
3	DECOMPOSE	What's the irreducible truth here?	Five Whys
4	REFRAME	Am I solving the right problem?	Abstraction Laddering
5	REBUILD	If I built this fresh, what would it look like?	First Principles
6	STRESS TEST	What guarantees this fails? Then what?	Inversion (Munger) + Pre-mortem (Klein) + Second-Order
7	DECIDE	Do I understand why convention exists before discarding it?	Chesterton's Fence

The Workflow (Rigid — No Skipping)

Step 1: DEFINE

State the problem in one sentence. The underlying need — not the solution you're evaluating.

Step 2: SURFACE ASSUMPTIONS

List every assumption using the 6 Socratic question types:

Type	Question
Clarification	"What exactly do I mean by X?"
Assumptions	"Why do I assume this? What if the opposite were true?"
Evidence	"What evidence supports this? Could it be wrong?"
Perspectives	"How would someone with zero context approach this?"
Consequences	"What happens if this assumption is wrong?"
Meta	"Am I solving the right problem?"

Categorize each assumption:

• Technical — "we need a database", "we need React"
• Convention — "best practice says X", "the framework expects Y"
• Constraint — "this has to be fast", "users need realtime"
• Organizational — "the team knows X", "we always do Y" (often the actual root cause — see Conway's Law: systems mirror the org chart that built them)
• Behavioral lock-in — "we can't change this, someone depends on it" (Hyrum's Law: every observable behavior of a system becomes someone's contract)

Step 3: DECOMPOSE (Five Whys)

Ask "Why?" five times. Each answer feeds the next question.

1. Why is the API slow?       → Query takes 3s
2. Why 3s?                    → 6-table join
3. Why 6 joins?               → Schema normalized for a different access pattern
4. Why that pattern?          → Copied from another project
5. Why copy it?               → "It's how we always do it" ← ROOT CAUSE (reasoning by analogy)

Stop when you hit a truth that cannot be decomposed further.

What legitimately counts as a fundamental truth:

• Physical limits (speed of light, cache line size, disk seek time, network RTT)
• Theorems (CAP, FLP impossibility, halting problem, Amdahl's law)
• Cognitive limits (Miller's 7±2, change blindness, working memory)
• Contractual / regulatory constraints written down somewhere
• Domain invariants (money cannot be negative; events have ordering; idempotency requires identity)

What is NOT a fundamental truth — keep digging:

• "The team prefers it" → why? (organizational, not technical)
• "It's faster" → measured how, against what baseline, on what workload?
• "It scales better" → past what threshold, with what traffic shape?
• "Best practice says so" → whose best practice, for what context?

Step 4: REFRAME (Abstraction Laddering)

Move UP and DOWN the abstraction ladder.

• UP ("Why does this matter?") — broader context, may reframe the entire problem
• DOWN ("How specifically?") — concrete constraints, implementation paths

If the problem looks different after reframing, return to Step 2 with the new framing. New framing → new assumptions to surface.

Step 5: REBUILD

Using only the truths from Steps 3-4, construct solutions from scratch.

What "from scratch" means in practice:

• Reject: the off-the-shelf solution catalog (Kafka, K8s, Postgres, React, GraphQL, etc.)
• Keep: the primitives the universe gives you (TCP, files, threads, SQL, HTTP, processes)
• Keep: existing constraints (legacy systems, team skills, deadlines, regulation)

Ask: "Given these constraints and primitives, what's the smallest thing that solves this?" Multiple candidates are fine — you filter in Step 6.

Step 6: STRESS TEST

Inversion (Munger, after Jacobi — "invert, always invert"): "What would guarantee this solution fails?"

• List failure modes explicitly
• Single points of failure?
• Does the solution avoid each one?

Pre-mortem (Klein): "It's one year from now and this decision failed catastrophically. Write the post-mortem." Concrete failure narratives surface risks that abstract inversion misses.

Second-Order Thinking ("And then what?" — at least 3 times):

• Downstream effects of this decision?
• New coupling, complexity, maintenance burden?
• Does it still make sense in 6 months? 2 years?

If critical failure modes appear, return to Step 5.

Step 7: DECIDE (Chesterton's Fence)

Now, and only now, compare your first-principles solution with convention.

Before discarding convention: "Do I fully understand why the conventional approach exists?" Chesterton's Fence: don't tear down a fence until you know why it was built.

Present the recommendation with:

• The fundamental truths it's grounded in
• How it differs from convention and why
• Honest tradeoffs — what you gain and what you lose
• If convention wins, state which first principle supports it

Lite Version (for medium-stakes, two-way-door decisions)

When the full 7-step workflow is overkill but you still want discipline:

1. DEFINE — one sentence
2. DECOMPOSE — Five Whys to root cause
3. STRESS TEST — one Inversion pass

~10 minutes. Captures most of the value when stakes don't justify the full ceremony.

When First-Principles Thinking Fails

First-principles can produce disasters when applied wrong. Counter-examples (survivorship-bias antidote):

Case	What Went Wrong
Apple Newton	Reinvented handwriting recognition from scratch; market mismatch + execution gap vs convention
Google Wave	Reimagined email; no one understood what it was for
Quibi	Reinvented mobile video from "first principles of attention"; $1.75B vaporized
Segway	Reimagined urban transport; ignored regulatory and social primitives
Theranos	"Existing blood machines are dumb" — ignored actual physical constraints
Juicero	Rebuilt juicing from principles; the bag could be squeezed by hand

Common failure modes:

• Domain ignorance — you don't know what you don't know about the existing solution
• Underestimating Hyrum's Law — every observable behavior of the convention has dependents you didn't see
• NIH syndrome dressed as first principles — "we'll build it ourselves" without honest cost accounting
• Survivorship bias — only the Prime Videos make headlines; the failed rebuilds quietly die
• Wrong abstraction level — first-principles at the wrong layer (rebuilding TCP when you needed a different message format)

Heuristic: if your rebuild ignores more than three things the convention handles, you probably haven't earned the right to rebuild.

Anti-Patterns

Anti-Pattern	How the Workflow Catches It
Reasoning by Analogy ("Netflix does X")	Step 2 forces why you assume the analogy holds
Cargo Cult — copying without understanding	Step 2 surfaces what you assume and why
Resume-Driven Dev	Step 3 decomposes to needs, not career goals
Hype-Driven Dev	Step 5 rebuilds from constraints, not HN frontpage
Premature Abstraction	Step 4 reframes at the right level before abstracting
Architecture Astronautics (Spolsky)	Step 1 forces a concrete problem statement
Inner-Platform Effect	Step 5's "smallest thing" rule resists DSL-inside-DSL
Vendor-Driven Design ("we use AWS, so Lambda")	Step 2 surfaces the org-as-constraint assumption
Speculative Generality (Fowler)	Step 4 reframes from hypothetical to real needs
Symptom Patching	Step 3 Five-Whys to root cause

Common Mistakes

• Stopping Five Whys too early. "The schema is bad" is a symptom. Keep going until you hit a non-decomposable truth, an organizational reality (Conway), or "we always do this" (cargo cult).
• Confusing constraint with convention. "Has to be fast" is a constraint only if you can name the latency budget. Otherwise it's convention.
• Skipping Step 7. Producing a clever first-principles answer without comparing to convention = you don't actually know why your answer is better.
• Reframing without returning to Step 2. New framing → new assumptions. Don't skip back.
• Treating "rebuild from scratch" literally. You're not reinventing TCP. You're rejecting the off-the-shelf catalog, not the universe's primitives.
• Applying the full workflow to two-way-door decisions. Reversible decisions: Lite Version or just ship.
• Mistaking org constraints for technical truths. "We can't" usually means "the team won't" or "the budget won't" — make that explicit instead of dressing it up.

Rationalizations — STOP If You Hear These

Excuse	Reality
"This problem is too simple for Five Whys"	Five Whys takes 60 seconds. Cost of skipping is finding root cause in production.
"I already know the answer — going straight to Step 5"	Skipping Step 2-3 means your answer is just a recycled analogy with extra steps.
"We don't have time for 7 steps"	Each step is 1-3 minutes for most decisions. Time pressure is exactly when assumptions go unchecked.
"Step 7 doesn't apply — convention is obviously wrong"	If you can't articulate why the convention exists, you haven't earned the right to dismiss it.
"The team won't accept the first-principles answer"	Then the org is the constraint (Step 2 / Conway). Surface it explicitly — don't pretend it isn't there.
"Inversion is just negativity"	Inversion is the cheapest way to find load-bearing failure modes. Munger built a fortune on it.
"This is a hotfix, no time for this skill"	Correct for the patch itself. The violation is skipping the post-incident workflow on the root cause within 48h.

Red Flags — You're Reasoning by Analogy

Stop and run this workflow when you catch yourself thinking:

• "Netflix / Google / Meta does it this way"
• "It's best practice"
• "The framework recommends..."
• "Everyone uses X for this"
• "We've always done it this way"
• "The blog post said..."
• "Stack Overflow says to just..."

Real-World Outcomes (selected)

• Amazon Prime Video — microservices → monolith, −90% cost. Data flow needed tight coupling, not distribution.
• 37signals — cloud → own hardware, $7M / 5yr saved. Stable traffic didn't need elastic scaling.
• LMAX Disruptor — understood CPU cache lines instead of conventional queues = 25M msg/s at <50ns latency.
• SQLite — built the DB from the problem (embedded, file-based) = most-deployed DB on Earth.
• Go — removed "essential" features (inheritance, exceptions, initial generics) = top-10 language.

For extended outcomes across API design, frontend, security, ML, and failed first-principles cases, see references.md.

Worked Examples

For full step-by-step applications of this workflow, see worked-examples.md:

• "Should we adopt Kubernetes?"
• "Should we rewrite the service in Rust?"
• "Why is our API slow?" (debugging path)

Further Reading

Canonical references, philosophical roots, and complementary frameworks: see references.md.

Essential starters:

• Brooks — No Silver Bullet (1986) — essential vs accidental complexity
• Moseley & Marks — Out of the Tar Pit (2006) — definitive on accidental complexity
• Ousterhout — A Philosophy of Software Design — complexity as the enemy
• McKinley — Choose Boring Technology (essay) — first-principles counterweight
• Hickey — Simple Made Easy (talk) — distinction between simple and easy