The Power of Good Enough: Inside the “Worse Is Better” Philosophy
Discover how the 'Worse Is Better' philosophy shows that simple, good enough solutions often outperform perfect designs.
Introduction: Why “good enough” so often wins
We love elegant designs that do everything “the right way.”
But in the real world, the solution that is simpler, ships earlier, runs anywhere, and evolves fast usually wins.
That is the heart of “worse is better”: start with a small, working core—even if it is incomplete—then improve it in the open, guided by real users.
Where the idea came fromComputer scientist Richard P. Gabriel contrasted two design cultures:
• The MIT / “Right Thing” approach: correctness, consistency, completeness, then simplicity.
• The New Jersey / “Worse Is Better” approach: simplicity first (especially implementation), accept partial coverage, refine later.
His claim: the “worse” approach spreads like a virus—it is easier to build, port, understand, and adopt. Once it spreads, it gets better.
The four core principles (and the trade-offs)
1) Simplicity first
• Worse Is Better (WIB): Keep the implementation tiny. Solve the common case with the fewest moving parts.
• Why it matters: Small things are easier to ship, port, secure, reason about, and maintain.
2) Correctness—promise less, keep all promises
• WIB: Be correct about what you do support; leave out rare edge cases for later.
• Why it matters: Tight scope reduces bugs, lets you deliver faster, and makes correctness achievable.
3) Consistency—avoid “overly” inconsistent
• WIB: Prefer dropping complex corners over introducing inconsistency or heavy machinery.
• Why it matters: Users forgive missing features more than unpredictable behavior.
4) Completeness—cover the 80%, not the 100%
• WIB: Serve the common paths well; add long tail features as demand proves out.
• Why it matters: Prevents bloat and lets real usage—not hypotheticals—shape the roadmap.
Why “good enough” dominates in the wild
Viral adoption
Small footprint, low dependencies, and modest hardware needs widen the audience immediately.
Portability as a force multiplier
Simple systems port faster, compilers are easier to write, and communities form earlier.
Faster feedback loops
A minimal, shippable product invites real users—and real telemetry—so iteration targets what matters.
Ecosystem gravity
Once widely adopted, tools, docs, plugins, and talent accumulate, making the platform steadily better.
Classic victories of “worse is better”
Unix & C
• Win factors: minimal kernel, simple abstractions, portable compilers, ran on weak hardware.
• Outcome: Ubiquity. A simple core that others could bend to their needs.
The Web (HTML/CSS/JavaScript)
• Win factors: forgiving standards, “view source,” zero-install distribution via browsers.
• Outcome: Messy beginnings, massive reach, then relentless hardening (ES6+, modules, modern CSS).
TCP/IP vs. OSI
• Win factors: working code, simplicity, deployment momentum.
• Outcome: TCP/IP became the internet’s backbone despite OSI’s conceptual elegance.
Agile + MVPs
• Win factors: deliver value fast, test with users, iterate.
• Outcome: Fewer grand failures; more products that actually fit markets.
Where “worse is better” can fail
Safety-critical systems
Medical, aerospace, autonomous systems: incomplete coverage can cost lives. Bias toward rigorous “right thing.”
Security and privacy
“Ship now, patch later” invites vulnerabilities. Simplicity helps security, but missing safeguards do not.
UX cohesion and tech debt
Quick accretions can calcify into awkward interfaces and brittle internals if refactoring is neglected.
Interdependent mega-systems
Large, tightly coupled platforms sometimes need stronger guarantees up front to avoid chaos.
Heuristic: The higher the cost of failure or change, the more you should lean toward the “right thing.”
A decision framework: When to prefer each
Ask these five questions:
1. Cost of being wrong?
Low → WIB.
High/irreversible → Right Thing.
2. Stability of requirements?
Unclear/fast-changing → WIB prototypes.
Stable/regulated → more up-front design.
3. Adoption constraints?
Need broad reach, varied environments → WIB’s portability.
Single, controlled platform → can afford RT.
4. Feedback loop speed?
Can you test quickly with users? → WIB thrives.
Long validation cycles → RT safeguards.
5. Ecosystem leverage?
Strong community and tooling → WIB compounds.
Sparse ecosystem → RT may prevent dead ends.
How to implement “worse is better” well
1) Define a sharp, minimal core
Pick the 2–3 must-win use cases. Keep the API tiny and composable.
2) Write down non-goals
Explicitly list what you are not solving yet. This prevents silent scope creep.
3) Design for evolution
Stable boundaries, versioning, feature flags, and migration plans. Make changing course cheap.
4) Instrument from day one
Metrics, logs, tracing, error budgets. Let data—not opinions—steer iteration.
5) Guardrails for quality
Automated tests, static checks, basic threat modeling, least-privilege defaults—lightweight but real.
6) Ruthless pruning
If a feature adds disproportionate complexity, remove it, make it a plugin, or defer it.
7) Iterate on the interface
Tighten naming, defaults, and docs as usage teaches you what is confusing.
Practical checklists
Before v1:
• What is the smallest thing that delivers real value?
• Can it run with fewer deps and less memory/CPU?
• Top three failure modes and safe fallbacks identified?
• Telemetry and basic tests in place?
• Non-goals documented?
After launch:
• Collect real usage data and support tickets.
• Ship small, frequent improvements.
• Pay interest: schedule refactors alongside features.
• Re-validate roadmap quarterly against actual demand.
Busting common myths
• Myth: “Worse is better = sloppy.”
Reality: It is disciplined minimalism with a plan to iterate.
• Myth: “Users need completeness.”
Reality: Users need reliable solutions to common problems now; completeness can follow demand.
• Myth: “You cannot do security with WIB.”
Reality: You can—via least privilege, safe defaults, and small attack surfaces—while deferring non-critical features.
• Myth: “It never becomes ‘the right thing.’”
Reality: Widespread adoption funds steady improvement from ~50% to ~90%—often enough to win.
Beyond software: Everyday applications
• Habits: Start with 2 push-ups daily; consistency beats perfect plans.
• Writing: Draft ugly, publish, revise; cadence > polish.
• Startups: MVP first; learn, pivot, scale.
• Learning: Build tiny projects; complexity grows with competence.
The balanced conclusion
“Worse is better” is not an excuse for cutting corners—it is a strategy for momentum:
• Start simple.
• Deliver value quickly.
• Earn adoption.
• Evolve with real feedback and guardrails.
In markets that reward speed, reach, and adaptability, the power of good enough beats the fantasy of perfect—especially when “good enough” is designed to get better every single release.
Authoritative Insights on the ‘Worse Is Better’ Philosophy
Through thorough research, analysis of software and design case studies, and evaluation of real-world examples, I explain why “good enough” solutions often outperform perfect designs. By breaking down the principles of the “worse is better” philosophy, I provide readers with actionable insights for understanding and applying simplicity in technology and decision-making.
Thank you!
Follow AZAD Search for practical tips from an architect, blogger, technical expert, and financer's lens.
Meenakshi (Azad Architects, Barnala)