Worse Is Better

Richard Gabriel's observation that simpler "worse" technologies often win adoption over more complete or "correct" ones by prioritizing implementation and interface simplicity and survivability over completeness — invoked to explain why inferior-but-simpler options (JSON, VHS) dominate superior alternatives.

Also known as: worse is better, Worse Is Better, worse-is-better, Richard Gabriel's worse-is-better, New Jersey style vs MIT style, popular despite superior alternatives, simplicity of interface over completeness, VHS versus Betamax

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (6)

• Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering David Gudeman · 2026-09-22 source ↗ Reader 🖥️
  A resource-constrained startup should bet on a managed platform (Firebase/GCP/Cloud Run) that lets it ship a working product immediately and evolve incrementally into a production-grade system without ever rewriting from scratch, and should architect its frontend as a thin reactive subscriber to the backend database rather than duplicating state client-side — because engineering time spent on infrastructure or state-synchronization busywork is time not spent learning what users actually want.
• Worse is better: C# versus F# Mark Seemann · 2026-09-08 source ↗ Reader 🖥️
  F# is superior to C# along most axes of comparison — decisively so in F#'s built-in, compiler-enforced prevention of circular dependencies, which C# is unlikely ever to match — even though F# is, ironically, the least popular of Microsoft's three officially supported .NET languages.
• JEP 540 Proposed to Target JDK 28 with a Simple JSON API A N M Bazlur Rahman · 2026-08-17 source ↗ Reader 🖥️
  JEP 540 proposes a deliberately narrow, strict, immutable, dependency-free JSON API for the JDK standard library — trading the completeness of libraries like Jackson and Gson for interface simplicity — and ships it as an incubating module so the community can pressure-test its navigation, exception, conversion and construction ergonomics before the design is finalized.
• Howard Yu's Post — American AI models went from 70% of usage to 30% in 12 months Howard Yu · 2026-07-11 source ↗ Reader 🖥️
  The AI-model market is flipping from US to Chinese dominance in real production usage, and the decisive driver is per-task cost — decisive precisely because the agentic era multiplies calls per task, so distribution consolidates on the cheapest 'good-enough' models faster than any residual US capability lead can matter.
• Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 source ↗ Reader 🖥️
  Users gain real agency over their data not by eliminating servers or fully decentralizing but by adopting open, standard protocols that keep data portable and provider-independent — the common principle Kleppmann traces from the unbundling of monolithic databases into modular building blocks, through BlueSky's AT Protocol, to the local-first software movement.
• Worse is better: JSON versus XML Mark Seemann · 2026-07-06 source ↗ Reader 🖥️
  Despite JSON's popularity, XML is the superior data-interchange format in most respects — because its mature ecosystem of standards (schemas, versioning, querying, streaming, even sum types) delivers real capability that JSON only reinvents piecemeal, while JSON's supposed advantages (informality, size, readability) are illusory, marginal, or equally achievable in XML — making JSON another case of 'worse is better'.

Propositions touching this concept (1)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• implicitcorroboratedTechnical superiority does not determine adoption; a technically inferior format can become dominant ('worse is better').
  Worse is better: JSON versus XML · p17

Open gaps (18)

• incompleteThe article notes JEP 198 (2014) was a broader, never-delivered predecessor but does not explain why it stalled, leaving the reader unable to judge whether JEP 540's narrower scope specifically fixes the reason the earlier attempt failed, or whether it risks repeating that failure for different reasons.
  JEP 540 Proposed to Target JDK 28 with a Simple JSON API — read next: JEP 198 itself and any OpenJDK retrospective or mailing-list history on why a JDK-native JSON API was proposed in 2014 and never delivered.
• incompleteDuplicate-member-name rejection is framed purely as a general interoperability inconvenience, but the article never connects it to the security literature on parser-differential attacks (where two parsers in a pipeline disagree on which duplicate key wins, enabling validation bypass or smuggling) — an angle where a strict, spec-first standard-library parser is unusually well positioned, but the piece doesn't make that case.
  JEP 540 Proposed to Target JDK 28 with a Simple JSON API — read next: Security research and write-ups on JSON/HTTP parser-differential and duplicate-key smuggling vulnerabilities.
• incompleteAdoption economics of decentralisation are left open. Kleppmann concedes that real decentralisation depends on funded alternative providers actually existing, but never examines why they would be funded or what sustains a commodity, easily-substitutable provider — the very portability that empowers users also destroys the provider's pricing power. Without a viable business model for the exit option, 'agency via guaranteed switching' risks staying hypothetical, as it largely did for email/XMPP federation.
  Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: Two-sided platform and commons-funding economics; the decline of federated protocols (XMPP, RSS) despite openness; Cory Doctorow on interoperability mandates as the missing forcing function.
• incompleteThe incentive against open sync protocols is unaddressed. The argument assumes vendors will adopt open, portable sync (like Git's) even though proprietary lock-in is precisely what makes SaaS valuable. No mechanism — market pressure, regulation, a standards body — is offered that would make an incumbent like Google standardise away its own moat, and the Git example itself shows incumbents keep the non-portable parts (GitHub issues, wikis) closed.
  Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: EU Digital Markets Act interoperability provisions; the history of why Google Docs never opened its sync; the switching-cost/moat economics already in this corpus (extract-mellbye-wrapper-vs-infrastructure).
• incompleteEnterprise, regulatory, and security fit of local-first is barely touched. With the primary copy of data spread across many user devices, questions of enterprise governance, GDPR / data-residency, audit trails, device loss or theft, and access control at scale go largely unexamined — Kleppmann names end-to-end encryption and decentralised access control only as work still in progress. The hard organisational tradeoffs of device-held data are not weighed against the user-agency benefits.
  Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: Data-sovereignty sources in this corpus; EU AI Act / GDPR data-residency obligations; enterprise endpoint-security and MDM literature for the device-loss and access-control problems.
• incompleteWho actually benefits and who bears the cost is not asked. The framing centres user empowerment, but shifting storage, compute, conflict-resolution, and support burdens onto clients and app developers — while removing the server's authoritative control — may not translate into real agency for a median, non-technical user. 'Agency' that is only exercisable by switching providers or self-hosting may be agency mostly for the already-technical.
  Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: Hirschman's 'Exit, Voice, and Loyalty' on the limits of exit-as-empowerment; empirical uptake of GDPR Article 20 data-portability rights; digital-literacy research on who can actually exercise portability.
• incompleteNo discussion of data-consistency or transactional trade-offs once multiple write paths exist (the REST endpoint he recommends, plus the client writes Firestore rules technically still permit and he only discourages rather than disables). No treatment of what happens under concurrent writes or partial failures.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Sources on Firestore/Firebase data-modeling and consistency guarantees, or on CQRS/command-endpoint patterns for NoSQL reactive databases.
• incompleteBets the company's entire stack on Google's platform for up to a decade without ever naming vendor lock-in or Google's own history of deprecating developer products as a risk to weigh against the velocity gains.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Vendor lock-in / platform-risk analyses for cloud-native startups; Google's product-deprecation track record.
• illogicalThe 'critical feature that turned out unused' anecdote is used to justify 'just build it and move on,' but the same evidence equally supports the opposite lesson — instrument usage or validate demand before building — which he never considers as an alternative.
  Presentation: Maximizing Success with Limited Time, Resources, and Energy: Lessons from Startup Engineering — read next: Lean/validate-before-build literature (e.g. Lean Startup) as a counter-framework to his 'ship fast, don't argue' heuristic.
• illogicalThe central 'F# has a larger unique-feature set, therefore it's superior' argument rests on a Venn diagram the author himself calls 'not to scale' and describing something that 'can't even be measured' — the same unweighed-capability move flagged as a central weakness in the predecessor JSON-vs-XML article, and in direct tension with the Best Simple System for Now view that more speculative capability and optionality make systems harder, not easier, to reason about and change.
  Worse is better: C# versus F# — read next: Re-read 'Applying Best Simple System for Now' (extract-applying-best-simple-system-for-now) alongside this piece to test whether 'F# has more features' is evidence of superiority or simply of more surface area, by the same standard BSSN uses against speculative extensibility.
• incompleteThe 'what C# does better' section lists real, current C# advantages (Razor/GUI support, IDE tooling, cyclomatic-complexity/coverage/mutation-testing tool support, programmer availability) but never weighs them against F#'s advantages in any explicit cost-benefit — each point is granted and then set aside ('I do occasionally find cyclomatic complexity useful, so it'd be nice to have tool support for that') rather than integrated into the overall superiority verdict, mirroring the same aggregation-without-weighing pattern flagged in the JSON-vs-XML predecessor article.
  Worse is better: C# versus F# — read next: Look for a practitioner cost-benefit account of migrating a real C# codebase to F#, weighing tooling gaps (mutation testing, coverage, IDE refactoring support) against the architectural and expressivity gains claimed here.
• incompleteThe article names 'declarative programming is harder to learn than imperative programming' as a likely driver of C#'s greater popularity, but explicitly declines to investigate whether this is inherent to human cognition or an artifact of how most programmers first encounter programming — leaving the actual mechanism behind F#'s unpopularity, and thus the practical case for or against teaching F# (or FP) first, unresolved.
  Worse is better: C# versus F# — read next: Read CS-education or cognitive-science literature on whether imperative-first instruction creates a lasting bias against declarative/functional thinking, versus functional programming being intrinsically harder to learn regardless of instruction order.
• incompleteThe claimed F# tooling deficit for mutation testing rests on information the author flags as possibly outdated ('last time I worked with mutation testing in .NET I found no F# support, but it looks as though Stryker has at least rudimentary F# support... I should look into that in the future') — the article's own concession that C# has a testing-tooling advantage is not verified as current at time of writing.
  Worse is better: C# versus F# — read next: Check Stryker.NET's current F# support maturity directly rather than relying on this now-superseded claim, especially since this extraction may itself now be dated.
• incompleteThe article asserts that ecosystem maturity/standardization makes XML 'superior' but never defines the criteria of superiority or weighs them against JSON's decisive real-world advantages — network effects, JavaScript-ecosystem gravity, and cognitive simplicity — which are the actual reasons formats win adoption. 'Superiority' is treated as a property of the format in isolation rather than of the format-in-its-ecosystem.
  Worse is better: JSON versus XML — read next: Read Richard Gabriel's original 'The Rise of Worse Is Better' — it argues that the 'worse' option's simplicity of interface is itself the deeper virtue, directly challenging the 'why reinvent the wheel' framing — alongside the network-effects and standards-adoption literature.
• illogicalThe recurring 'why reinvent the wheel?' treats JSON's re-implementation of XML capabilities as pure waste, but the very fact that the ecosystem chose to reinvent a SIMPLER wheel is evidence that XML's richer wheel was mis-sized for the common case. The argument thus assumes what it needs to prove — that XML's heavier standards are worth their cost — and this directly contradicts the Gabriel 'worse is better' thesis Seemann himself invokes as his framing device (a tension the article never acknowledges).
  Worse is better: JSON versus XML — read next: Engage Gabriel's actual claim that simplicity of the common case can rightly dominate completeness, and read the design-fundamentals argument that unused capability is a cost, not a latent asset.
• incompleteThe size argument is dismissed too quickly — 'when performance really is a consideration, JSON may be too big, too' waves away rather than engages the large middle band of high-throughput text APIs (aggregate bandwidth, parse cost, streaming) and the schema-driven binary formats that are actually chosen when neither text format fits.
  Worse is better: JSON versus XML — read next: Read the schema-driven binary serialization literature — Protocol Buffers, Apache Avro, Cap'n Proto, MessagePack — to see where the real interchange-format frontier lies beyond the XML-vs-JSON text axis.
• incompleteThe Hyrum's-law/implicit-contract point is used only against JSON, but it cuts both ways: XML with an XSD still couples consumers to undocumented behaviors, and a schema is not a free lunch — XSD complexity, schema evolution, and versioning cost are never weighed against the benefit claimed.
  Worse is better: JSON versus XML — read next: Read on schema evolution and compatibility (e.g. Avro/Protobuf compatibility rules, and API-versioning practice) to see the ongoing cost side of the schema ledger the article omits.
• incompleteThe configuration-file case rests almost entirely on JSON's lack of standard comments, yet never mentions YAML, TOML, or HCL — the formats that actually displaced both XML and JSON for configuration — which makes the 'XML for config' recommendation weaker and more dated than presented.
  Worse is better: JSON versus XML — read next: Compare TOML and YAML directly on the same criteria (comments, readability, schema tooling) to see why the config-format question was largely settled without either XML or JSON winning.