When First Principles Is Wrong
First principles thinking is powerful. It is also expensive. And sometimes it is the wrong tool entirely. The engineer who tries to reason from fundamentals about every decision will move at a fraction of the speed of one who knows when to use analogy instead. The judgment is not "always use first principles" — it is knowing which mode to use for which problem.
The Cost of First Principles
Every application of first principles thinking has a cost: time, cognitive effort, and opportunity cost of not spending that time elsewhere. Breaking a problem down to its fundamentals, questioning every assumption, and reasoning upward from scratch takes hours or days. For important, novel problems, that investment pays off. For routine, well-solved problems, it is waste.
Problem Cost of first principles Payoff
--- --- ---
"How should we architect the 2 days of deep analysis High. Novel
new data pipeline?" problem with
years of impact.
"Which HTTP library should 1 day of research Low. All popular
we use?" options are fine.
"Should we use JWT or 3 days of security Negative. Smart
session tokens?" analysis from scratch people already
solved this.
"How should we handle 1 week of reinventing Dangerous. Use
authentication?" a solved domain a proven library.
The third and fourth rows are where first principles thinking becomes actively harmful. Not because questioning is bad, but because the cost of deriving the answer from scratch exceeds the cost of adopting a well-proven solution.
When Analogy Is Fine
Reasoning by analogy — "Company X solved this with approach Y, and our problem is similar enough that Y should work for us too" — is the right choice when:
- The problem is well-understood and widely solved
- The solutions are mature and battle-tested
- The cost of being wrong is low
- The cost of analysis exceeds the cost of mistakes
- Your problem is genuinely similar to the reference case
Good uses of analogy:
"How should we structure our REST API?"
Follow the conventions. Use standard HTTP methods, status codes,
and resource naming. Thousands of teams have iterated on this.
Your API is not special enough to justify novel design.
"What database should we use for our CRUD app?"
PostgreSQL. It is what everyone uses for good reason. Unless you
have a specific reason to choose otherwise, this is the default.
"How should we set up CI/CD?"
Copy a working configuration from a similar project. Customize later.
Nobody needs to derive CI/CD from first principles.
"What should our code review process look like?"
Start with what works at well-run companies: author writes a clear
description, reviewer checks for correctness and clarity, one
approval required. Adjust after a few months of experience.
In all these cases, the problem has been solved many times by many competent teams. Your context might require adjustments, but the foundation does not need reinvention.
Don't Reinvent Auth
Authentication and authorization are the canonical examples of problems you should not solve from first principles. The domain is complex, the consequences of mistakes are severe, and the solutions are mature.
First principles approach to auth:
"What do we fundamentally need? A way to verify identity.
Let's build our own token system. We'll hash the user ID
with a timestamp and a secret..."
Stop. This path leads to CVEs.
Analogy approach to auth:
"Every mature web framework has auth middleware. OAuth 2.0 is
a standard. Auth0, Cognito, and Firebase Auth exist. Let's
use one of them."
The first principles approach to auth ignores a critical fact: the security domain has failure modes that are invisible to non-specialists. You will not discover them by reasoning from fundamentals. You will discover them when an attacker exploits them in production.
The same applies to:
Domain Why not first principles
--- ---
Cryptography Subtle mathematical attacks you won't think of
TLS/SSL Decades of protocol-level vulnerabilities found
and patched by specialists
Password hashing bcrypt, scrypt, and argon2 encode knowledge
that is not derivable from first principles
SQL injection prevention Use parameterized queries. Do not build your
own sanitization logic.
These are domains where the gap between "I reasoned about this carefully" and "the security community has iterated on this for 20 years" is measured in data breaches.
Don't Redesign TCP
Networking protocols are another domain where first principles thinking is usually wrong. TCP, HTTP, DNS, and TLS represent decades of engineering by some of the smartest people in the field, with real-world feedback from billions of connections.
"Why does TCP use a three-way handshake? What if we used two?"
You could. QUIC essentially does this. But it took Google's
networking team years to make it work reliably. Unless you
are Google's networking team, use TCP.
"Why can't we just use raw UDP for everything?"
You can. Now you need to implement reliability, ordering,
congestion control, and flow control. Congratulations, you've
built a worse version of TCP.
"Our custom binary protocol would be faster than HTTP."
Faster, yes. But you lose caching, proxying, load balancing,
monitoring tools, developer familiarity, and debugging tools.
Is the speed gain worth all that?
The lesson is not "never question protocols." The lesson is that when a solution has been iterated on for decades by a global community, the burden of proof for replacing it is very high.
The Spectrum Between First Principles & Analogy
Most real decisions are not purely first principles or purely analogy. They sit on a spectrum, and the skill is knowing where on the spectrum a given problem falls.
Pure analogy Pure first principles
| |
"Use Postgres" "Use their architecture "Design a novel
as a starting point distributed consensus
but adapt for our algorithm for our
constraints" specific network
topology"
| |
Low cost, Moderate cost, High cost,
low risk moderate payoff high potential payoff
Most engineering decisions should sit in the left or middle of this spectrum. The right side is reserved for problems where conventional solutions genuinely do not work.
The Adapt Pattern
The most practical approach for many decisions is what you might call "analogy-then-adapt": start with a proven solution, and apply first principles only where your problem diverges from the reference case.
Step 1: Start with analogy.
"Stripe uses a request-ID-based idempotency system. Let's start there."
Step 2: Identify divergence.
"Our system has multi-step transactions that Stripe's model
doesn't handle well."
Step 3: Apply first principles to the divergent part.
"For multi-step transactions, what do we fundamentally need?
We need each step to be idempotent independently and the
overall sequence to be resumable. That means..."
Step 4: Combine.
"We use Stripe's approach for simple requests and our custom
approach for multi-step transactions."
This gives you 80% of the benefit of first principles at 20% of the cost, because you only reason from fundamentals where the standard approach breaks down.
Decision Framework
When facing a technical decision, ask these questions to determine which mode to use:
Question If yes...
--- ---
Has this problem been solved many times Use analogy.
by competent teams?
Are the consequences of a suboptimal Use analogy. Ship faster.
choice easily reversible?
Is this a security-sensitive domain? Use analogy. Use proven tools.
Is the problem genuinely novel for your First principles is justified.
context and the standard approach failing?
Are the stakes high and the decision First principles is justified.
irreversible?
Is the existing solution clearly wrong First principles, but start by
for your case? understanding WHY the existing
solution exists before replacing it.
The Chesterton's Fence Principle
Before you tear down a solution and replace it with something derived from first principles, understand why the existing solution was built that way. G.K. Chesterton's principle states: do not remove a fence until you understand why it was put there.
Scenario: Your codebase has a seemingly unnecessary caching layer
that adds complexity.
Bad approach:
"This cache is unnecessary. Our database can handle the load.
Let me remove it." (First principles without context.)
Good approach:
"Why was this cache added? Let me check the git history.
Ah — it was added during a traffic spike in 2024 when the
database was overloaded. The database has since been upgraded.
Let me verify that the current database can handle the load
without the cache before removing it."
Chesterton's Fence is the safety check on first principles thinking. It ensures you are not reasoning from incomplete fundamentals — that you understand the historical context before declaring it irrelevant.
Common Pitfalls
- First principles as identity — some engineers pride themselves on "thinking from first principles" and apply it to everything, including problems that do not warrant it. This is ego, not engineering.
- Not-invented-here syndrome — rejecting proven solutions because "we can build something better" is first principles thinking gone wrong. You almost certainly cannot build a better database than the Postgres team.
- Underestimating hidden complexity — when you derive a solution from first principles, you often miss the edge cases that existing solutions handle. Authentication, time zones, character encoding, and floating-point arithmetic are all domains full of invisible complexity.
- Speed-to-judgment — "this is a solved problem, use the standard approach" can become a reflexive dismissal that prevents useful questioning. Some problems look solved but are not — the standard approach may be widely adopted but subtly wrong for your use case.
- Binary thinking — treating the choice as "first principles vs analogy" when most decisions benefit from a blend. Start with analogy, apply first principles where the analogy breaks.
Key Takeaways
- First principles thinking is expensive. Use it for novel problems and high-stakes decisions, not for every choice.
- Reasoning by analogy is the right approach for well-solved problems: auth, networking protocols, standard architecture patterns, tool selection.
- The adapt pattern — start with analogy, apply first principles where your problem diverges — gives most of the benefit at a fraction of the cost.
- Before replacing an existing solution with a first-principles derivation, understand why the existing solution was built that way (Chesterton's Fence).
- The judgment that separates good engineers from great ones is knowing which mode to use for which problem.
- Security-sensitive and protocol-level domains are almost always better served by proven solutions than by novel reasoning.