Modularity & Coupling

Structural boundaries and dependency discipline in codebases — the properties that determine whether humans and agents can change a system safely.

Also known as: coupling data, coupling, loose coupling, modularity, dependency rules, independent deployability / independent reversibility, independent deployability, AI modularity review, impact radius, transactional coupling, separation of concerns / contracts / tenancy boundaries, leaky abstraction

How authors use it

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

Documents (23)

• Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers Chintan Tank · 2026-09-23 Reader 🖥️
  At multi-tenant SaaS scale, a monolithic edge worker's deployment coupling and unbounded blast radius stop being tolerable, so the fix is to decompose it into a thin composing gateway plus independently owned, tested, and staged-release feature workers connected by Cloudflare's same-isolate service bindings — the one primitive that makes this decomposition free of the network-hop cost that normally makes splitting a backend monolith expensive — while treating multi-CDN portability, per-feature configuration, and graceful failure as first-class, non-negotiable design constraints rather than afterthoughts.
• 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.
• Presentation: Understanding Progressive Collapse: How To Avoid A Cascading Failure Sam Newman · 2026-08-19 source ↗ Reader 🖥️
  Progressive collapse — civil engineering's term for a small, localized failure cascading into a system-wide catastrophe — is a productive lens for distributed-systems resilience: mitigation requires reducing hazards, strengthening components, and reducing interconnection together, but each mitigation (redundancy, multi-region, circuit breakers) carries real cost and complexity and can itself introduce new interconnection and new failure modes, so teams must apply these techniques as conscious, business-contextualized trade-offs rather than default best practice.
• 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.
• Presentation: Parting the Clouds: The Rise of Disaggregated Systems Murat Demirbas · 2026-07-30 source ↗ Reader 🖥️
  Cloud economics (the differing cost, scaling, and statefulness profiles of compute versus storage) is forcing database architectures toward disaggregation, and this shift is not a novel invention but a rediscovery of Lamport's original three-role decomposition of Paxos (proposer/acceptor/learner) — so the tradeoffs, optimizations, and open problems of today's disaggregated systems can be understood, and addressed, through decades of prior consensus-protocol research.
• The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices Prashanth Pasham · 2026-07-28 source ↗ Reader 🖥️
  By imposing an absolute rule -- never modify the legacy HCM monoliths again, only add new domain microservices -- and pairing it with three platform investments (self-service provisioning, an API-gateway routing seam, and a cached feature-flag rollback layer) that keep the resulting per-story cost tax affordable, a team can fund and execute a full monolith-to-microservices migration as a side effect of ordinary roadmap work, with no dedicated migration budget or program.
• Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere Elena van Engelen · 2026-07-27 source ↗ Reader 🖥️
  Structuring Function-as-a-Service applications with a simplified Clean Architecture — a domain and application layer with zero cloud dependencies, whose separation from infrastructure is enforced not by convention but by Gradle module boundaries, wired to cloud entry points via Spring Cloud Function's dependency injection — lets a team write business logic once and deploy it, materially unchanged, to multiple serverless cloud providers, eliminating vendor lock-in without giving up native cloud capabilities.
• Netflix Details Its In-House LLM Serving Platform with Triton and vLLM Matt Foster · 2026-07-27 source ↗ Reader 🖥️
  A shared serving interface (an OpenAI-compatible API sitting atop Netflix's JVM routing layer, Triton, and vLLM) can give application teams a stable integration surface across changing models and hardware, but only by continuously absorbing — not eliminating — the engineering work of version compatibility, stateful-feature correctness, and deployment isolation at the layers beneath it.
• DoorDash Uses Envoy and Valkey for a 1.5M RPS Proxy Cache with 99.99999% Availability Leela Kumili · 2026-07-20 Reader 🖥️
  DoorDash's Entity Cache shows that moving caching out of individual services and into a transparent, infrastructure-layer proxy (Envoy + Valkey) — with event-driven invalidation, staleness-tolerant failure handling, and stampede-avoidance techniques — can absorb very large request volume at extremely high availability without requiring any application code changes.
• AI Is Changing Software Engineering. The Fundamentals Still Matter. Abby Bangser · 2026-07-07 source ↗ Reader 🖥️
  AI is transforming who produces, consumes, and maintains software, but the organisations moving fastest succeed by doubling down on engineering fundamentals — right-sized boundaries, modular abstractions, clear interfaces, and operational discipline — as the foundation that lets humans and AI build together safely and sustainably.
• The "funhouse mirror": How AI reflects the hidden truths of your software pipeline Rachel Laycock (interviewed by The New Stack) · 2026-07-07 source ↗ Reader 🖥️
  AI is not a disruptor but an amplifier of your existing pipeline, so because writing code was never the bottleneck, its coding speed turns a velocity multiplier into a debt accelerator wherever software-delivery fundamentals, guardrails, and stewardship of newcomers are not already in place.
• Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 source ↗ Reader 🖥️
  In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering.
• 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'.
• Shifting Platform Development from Projects to Products Ben Linders · 2026-07-02 source ↗ Reader 🖥️
  Once an internal platform outgrows serving a single team, the project model — upfront scope, milestone delivery, and velocity/completion metrics — stops producing a coherent, usable system, and the platform must instead be run as a product: driven by user problems, hypothesis-based roadmaps, self-service APIs, clear tenancy boundaries, and adoption metrics.
• 18) Vipps: Fra app til verb til nordisk infrastruktur Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-06-01 source ↗ Reader 🖥️
  Vipps's evolution — from a 2015 DNB-internal P2P app built under an IT freeze, through three successive mergers (MCash 2017, BankAxept 2018-ish, MobilePay 2023), three markets, and a near-decade of platform rewrites — shows that becoming Nordic critical infrastructure is less about visionary architecture than about repeatedly choosing momentum over perfection: small monoliths first, big-bang cut-overs when integration matters more than iteration, and a relentless willingness to throw away technology, organisation and product features that no longer serve the next size of company.
• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery Ben Linders · 2026-05-21 source ↗ Reader 🖥️
  Internal platforms should be run as products that expose composable 'golden bricks' rather than prescriptive 'golden paths,' so that developer teams can self-assemble their own flow of value with low cognitive load while the platform team is held accountable to adoption, experience, and DORA-like outcome metrics.
• Three more static code analysis sensors Birgitta Böckeler (published on martinfowler.com) · 2026-05-20 source ↗ Reader 🖥️
  For maintainability concerns that cross file and module boundaries, computational static-analysis sensors (dependency rules, coupling metrics) can usefully enforce a few structural invariants but cannot judge what coupling is appropriate; the most productive sensor is an inferential, prompt-driven AI modularity review that reads the code itself, with the deterministic tools relegated to enforcement of known rules and to triage of review attention.
• The Organization Is the Bottleneck Sarah Wells · 2026-04-20 Reader 🖥️
  AI coding agents amplify an organization's existing engineering maturity rather than substituting for it; the same foundations that made microservices succeed — guardrails, deployment pipelines, engineering enablement — are prerequisites for succeeding with AI agents, so the real bottleneck is organizational, not technological.
• Agents don't know what good looks like. And that's exactly the problem. Luca Mezzalira · 2025-01-01 source ↗ Reader 🖥️
  Agentic AI systems lack the judgment to distinguish correct behavior from merely passing checks, which means that deterministic architectural guardrails — fitness functions, capability verification, explicit boundary definitions — are not optional but imperative; and the sociotechnical readiness of the humans and organizations that must own the generated systems is the overlooked bottleneck.
• Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 SQUER Solutions · 2024-06-11 source ↗ Reader 🖥️
  Successful architecture modernization is primarily an organizational and narrative problem, not a technology-upgrade problem: it succeeds when architects treat the value stream (business domain + outcomes + team autonomy + deployability) as the real unit of design, triage the system as a portfolio rather than rebuild it wholesale, and use social tools (listening, impact mapping, event storming, enabling teams, early visible wins) to earn and sustain the organizational permission that technical skill alone cannot secure.
• What good software looks like at REA Alison Rosewarne · 2018-06-12 Reader 🖥️
  What makes software 'good' at REA is not a single abstract ideal but three concrete, criteria-based lenses — dev (changeability), ops (operability), and arch (bounded responsibility) — that the teams who own each system rate themselves against on a recurring basis, so architectural quality becomes an organizationally-supported habit rather than a one-time design decision.
• Software Design X-Rays Adam Tornhill · 2018-03 source ↗ Reader 🖥️
  The real cost and risk in a large codebase is invisible in the code's current structure and can only be recovered by mining version-control history as a behavioral record of how people actually work on it — and once recovered (as hotspots, change coupling, code age, developer fragmentation, and knowledge maps), that record should drive both technical refactoring priorities and the alignment of team structure with system structure (Conway's Law), because most expensive software problems are organizational problems wearing a technical disguise.

Propositions touching this concept (25)

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

2018-03

• explicitChange coupling (files or functions that change together over time) is invisible in the code itself and detectable only by mining version-control history; the most valuable findings are 'surprising' couplings with no visible static dependency, because those point to hidden dependencies or missing abstractions.
  Software Design X-Rays · p8
• explicit'There's no such thing as just test code': unit tests that change together for reasons unrelated to the application code they test reveal missing test-design abstractions (shared test data, custom assertions), and poorly designed test suites become a disproportionate source of hotspots and change coupling.
  Software Design X-Rays · p9
• explicitChange-coupling analysis can suggest domain-driven-design bounded contexts directly from how the code actually evolves — sometimes revealing a bounded context the documented or intended architecture fails to capture.
  Software Design X-Rays · p20
• explicitMicroservice architectures reproduce the coordination problems of layered monoliths at a different granularity: implicit change coupling across repository boundaries ('microservices shotgun surgery'), monolithic UIs that re-centralize what the backend split up, and technical sprawl from divergent per-service languages/frameworks that erodes the 'conservation of familiarity' Lehman's laws require.
  Software Design X-Rays · p21

2024-06

• explicitA technology-only modernization (new infrastructure, languages, libraries) delivers real productivity gains but leaves the underlying domain-model coupling and abstraction problems untouched, so it only captures part of modernization's possible value.
  Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 · p2
• explicitInvisible 'change coupling' — needing to touch many technically unintegrated services to ship one feature — is a more reliable signal of poor domain boundaries than the absence of direct API or database coupling.
  Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 · p4

2026-04

• explicitGood architecture is the architecture that lets teams ship with minimum friction; loose coupling and high cohesion are the two levers, and they are general enough to settle most architecture arguments.
  14) Øystein Ulseth pendler mellom å lede og levere · p11

2026-05

• explicitFolder-based dependency rules need a meta-rule that any new file must be located inside the predefined folder structure; otherwise the agent escapes the system by inventing new folders.
  Three more static code analysis sensors · p5
• explicitEven a strong model (Claude Opus 4.7) interpreting raw coupling metrics produces lackluster, often wrong, findings because it cannot tell intentional patterns (DI factories, shared frontend/backend schemas) from coupling smells.
  Three more static code analysis sensors · p8
• explicitIf raw coupling metrics are used as input to an LLM, legitimate high-coupling hubs must be suppressible, or the noise compounds.
  Three more static code analysis sensors · p9
• explicitCoupling metrics' best use is triage of human (or agent) attention during code review — surfacing changes whose blast radius is large — not autonomous quality judgement.
  Three more static code analysis sensors · p10
• explicitAI agents will, by default, copy-paste rather than refactor toward shared abstractions even after several repetitions; the modularity review fills that gap.
  Three more static code analysis sensors · p12
• explicitWithout periodic AI modularity review (and without expert human review), an agent reliably compounds inadvertent technical debt at the modularity level.
  Three more static code analysis sensors · p14
• explicitcorroboratedFor modularity, computational sensors alone are insufficient; semantic interpretation by an LLM is required.
  Three more static code analysis sensors · p15
• implicitLayered architecture (routes → services → clients + domain, no I/O in services, etc.) is the right modularity target for this kind of TypeScript web app.
  Three more static code analysis sensors · p17
• implicitMaintaining the rule-set and the custom coupling-analyser is itself a cheap, sustainable activity once AI helps author them.
  Three more static code analysis sensors · p18
• implicitOff-the-shelf 'skills' from named experts (Khononov's Modularity Skills) raise the floor of LLM code review enough that organisations need not author their own modularity prompts.
  Three more static code analysis sensors · p19
• implicitModularity problems are detectable but not autonomously fixable by the same agent that introduced them; a separate review run is needed.
  Three more static code analysis sensors · p21

2026-07

• explicitThe same right-sizing and modularity discipline applies across three layers — human teams, the code base, and agent ecosystem access.
  AI Is Changing Software Engineering. The Fundamentals Still Matter. · p3
• explicitcorroboratedThe fundamentals of software engineering — well-written, well-architected, modular systems — matter more, not less, in the agentic age, because modularity is what makes systems understandable and changeable.
  The "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p6
• explicitcorroboratedNot all software is created equal in risk and business value, so enterprises should tier where they allow more agentic code generation and self-healing versus where they keep more humans in the loop with stronger guardrails, modularity, and incident-response capability.
  The "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p13
• explicitPackaging models via Triton's vLLM backend, rather than its Python backend, lets models and frontends evolve more independently — the choice affects coupling tightness to the serving environment, not which engine performs inference.
  Netflix Details Its In-House LLM Serving Platform with Triton and vLLM · p6
• explicitLow-level code-quality concerns (naming, duplication, dead code, modularity, coupling, cohesion) remain important in agentic development because LLMs share human-like readability limitations, because quality's payoff is long-term rather than short-project-scale, because complexity inflates both the LLM's context window and token cost, because humans must debug unfamiliar agent-written code the LLM itself can't fix, and — most consequentially — because LLMs mimic and reinforce the existing style and patterns of the codebase they generate into, entrenching rather than correcting bad code.
  Software Design in the Agentic Age: Placing Your Bets · p1
• explicitCode-level design concerns (naming, duplication, dead code, mixing responsibilities, modularity, coupling, cohesion) are largely automatable by agentic pipelines.
  Software Design in the Agentic Age: Place Your Bets · p1

2026-09

• implicitSplitting a shared worker into a chain of feature workers necessarily degrades single-request observability — no worker sees the whole request end to end unless diagnostics are explicitly threaded back through response headers — so modularity trades away a property (whole-request tracing) that the monolith provided for free.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers · p17

Tensions

Open gaps (63)

• uninformedThe article's optimism about a calibrated agentic judge reliably assessing boundary fidelity from ADRs, ownership metadata, and package graphs doesn't engage a directly relevant finding already in this corpus: extract-fowler-bockeler-static-sensors-iii found that even a strong model (Claude Opus 4.7) interpreting raw coupling metrics produced 'lackluster, often wrong' findings when it could not distinguish intentional patterns (DI factories, shared frontend/backend schemas) from genuine coupling smells — a near-identical judgment task to boundary-fidelity review.
  Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules — read next: extract-fowler-bockeler-static-sensors-iii (same corpus) — read the specific failure modes an LLM shows when interpreting structural/coupling evidence without richer context.
• unasked questionThe essay uses the Dreyfus model to characterize agents as novice/advanced-beginner but never asks whether the Dreyfus model, developed for human skill acquisition, is even the right frame for AI systems that learn in fundamentally different ways. Agent capabilities may not map onto a linear human progression scale at all.
  Agents don't know what good looks like. And that's exactly the problem. — read next: Literature on AI capability evaluation frameworks that are not anthropomorphic (e.g., benchmarks, formal verification, capability elicitation research).
• implicit premiseThe argument that 'more context degrades output' treats current LLM context-handling limitations as a stable architectural constraint rather than a temporary engineering limitation. If context handling improves significantly, the 'deterministic guardrails' prescription may need rebalancing.
  Agents don't know what good looks like. And that's exactly the problem. — read next: Research on long-context model performance, retrieval-augmented generation, and structured context management.
• incompleteThe evidence is anecdotal and constrained by the Chatham House Rule; the one quantified claim — that a modular refactor improved token usage and solution quality — is a single hallway-track data point with no magnitude, methodology, or generality.
  AI Is Changing Software Engineering. The Fundamentals Still Matter. — read next: Look for controlled studies on codebase modularity and file granularity versus LLM token cost and solution quality.
• incomplete'Right-sizing' is presented as clearly beneficial, but the author concedes many are 'still figuring out which primitives they are and how best to invest in them' — the piece provides no heuristic for finding the right boundary or context size.
  AI Is Changing Software Engineering. The Fundamentals Still Matter. — read next: Read on modularity heuristics such as Ousterhout's deep modules, and on context-window budgeting for LLMs.
• incompleteThe talk demonstrates portability for a toy two-function application with exactly one storage interface and one email interface; it doesn't show how the pattern holds up with dozens of business services, multiple storage backends, queues, and secrets managers, where interface proliferation and dependency-injection wiring complexity could become their own maintenance burden.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere — read next: Look for case studies or post-mortems of large-scale multi-cloud Clean-Architecture systems at real organizations, to see whether the pattern holds under complexity or only at demo scale.
• incompleteThe cost of this approach relative to its benefit is never argued. Extra interfaces, Gradle module boundaries, DI wiring, and CDK complexity have a real engineering cost, but the talk never weighs that against the — for many teams, mostly hypothetical — benefit of actually being able to switch or dual-run cloud providers, when most organizations pick one primary cloud for reasons (pricing, existing platform investment) unrelated to code portability and rarely execute a true migration even when the code is portable.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere — read next: extract-outsourced-ai-still-own-the-risk#p10 raises the structurally identical unresolved premise in the AI-vendor-lock-in context ('portability is achievable enough to function as a real hedge') — worth reading together to test whether 'engineered portability' claims generalize across domains or share the same unexamined cost side.
• uninformedThe Q&A's observability answer treats 'generic logger + cloud-specific sink config' as basically solving cross-cloud observability, but doesn't address the harder problems: correlating a single business transaction's logs, traces, and metrics when parts of it run on AWS and parts on Azure, distributed tracing across clouds, or cost/retention differences between CloudWatch and Azure Monitor.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere — read next: extract-infoq-data-driven-platform-engineering (platform engineering and observability federation across a real multi-cloud platform) and writing on OpenTelemetry's cross-cloud adoption as the actual mechanism for correlating traces, not just directing log lines.
• uninformedThe entire architecture is justified by a cost argument — that service bindings remove the network-hop cost that normally makes decomposition expensive — yet the article gives no quantitative figures anywhere: no latency number for a service-binding call vs. a same-worker function call, no CPU-ms budget figures, no request-volume or dollar-cost data. The only concrete scale figure in the whole piece is "hundreds of thousands of tenant accounts."
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Cloudflare's own published isolate/service-binding latency benchmarks, or a follow-up practitioner piece with production percentile latency and CPU-budget numbers for a comparable gateway-plus-feature-workers deployment.
• incompleteThe gateway itself is never examined as a newly concentrated point of ownership and failure. "Ownership mismatch" was named as one of the four original complaints against the monolith, yet the article never addresses who owns the gateway's composition order, how conflicts between features that both want early position in the fixed sequence are resolved, or how gateway ownership itself scales as feature teams multiply.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: extract-evolutionary-architecture-pattern-for-managing-ais-pace-of-change#g1 raises the structurally identical unexamined-gateway-concentration blind spot in a different (AI-governance) domain; platform-engineering literature on control-plane ownership and internal-platform product ownership would also speak to this.
• incompleteThe "degrade to origin" rule is presented as unconditionally safe, but the article never considers cases where the unoptimized origin response is itself unacceptable — a client device that genuinely cannot render the origin format, or a tenant whose cost/bandwidth contract depends on the optimization having actually run. The fallback's own failure mode is left unexamined.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Would benefit from engaging with graceful-degradation literature that treats the fallback path itself as a design surface with its own failure modes, not an automatically safe default.
• incompleteThe article names the observability loss caused by decomposition (diagnostics captured inside a downstream feature worker are not propagated back through the gateway) but never describes how the team actually debugs a failing request in production once it crosses a service-binding boundary — the fix for the gap it identifies is left unstated.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Distributed-tracing / observability practice for chained service-to-service calls (e.g., correlation IDs threaded through headers, structured logging aggregation) would close this.
• incompleteThe talk's central analogy (Paxos's proposer/acceptor/learner = disaggregated compute/log-store/page-store) is argued from role-count and role-function correspondence, but never examines whether the actual consistency and safety mechanisms engineered into commercial systems — Aurora's specific 4-of-6 storage quorum, PolarDB's 'parallel Raft' — were derived from, or are even formally equivalent to, Paxos's quorum-based correctness guarantees. It is left unclear whether this is a rigorous technical lineage or a structural resemblance noticed after the fact and narrated as history.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Compare the Aurora and PolarDB architecture papers' own consistency arguments against Lamport's Paxos correctness proof, to see whether their quorum choices were derived from consensus theory or arrived at independently by systems engineers optimizing empirically for latency and durability.
• incompleteThe list of production disaggregated systems (Aurora 2015 through Amazon DSQL 2025) is presented as confirmatory evidence that disaggregation 'is already here' and validated, with no counter-examples, documented cost overruns, performance regressions, or teams that reverted from disaggregated to monolithic designs — a one-sided evidentiary base for what is framed as an economically inevitable trend.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Look for independent benchmarks or critical retrospectives comparing Aurora/PolarDB/AlloyDB total cost of ownership and performance against self-hosted or lift-and-shift Postgres/MySQL, to test whether 'cloud economics demands disaggregation' holds outside an idealized cost model.
• illogicalThe 'ingrained fault tolerance' principle (build consensus into the database rather than depend on an external configurator) is asserted without reconciling that internalizing consensus reintroduces the coordination overhead that motivated separating log stores and page stores from compute in the first place. The author himself concedes the shared-log/virtual-log research branch he praises still depends on an external metastore ('I'll live with it'), which undercuts the principle's own claim to full self-containment without resolving the tension.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Read Mahesh Balakrishnan's shared-log/virtual-log work for how it explicitly handles this exact tradeoff, rather than fully internalizing consensus — it may show that full self-containment is not achievable in practice and 'ingrained fault tolerance' is aspirational rather than a settled design principle.
• incompleteNo comparison to alternative architectures for the same problem — CDN-style edge caching, a shared client-side/library cache instead of a proxy, a dedicated caching-as-a-service product, or a simpler TTL-only cache without event-driven invalidation — so a reader can't tell whether the added complexity (Kafka pipeline, dual TTL, single-flight, XFetch) is justified relative to simpler designs, or what specifically necessitated the proxy-layer approach over a client-library approach.
  DoorDash Uses Envoy and Valkey for a 1.5M RPS Proxy Cache with 99.99999% Availability — read next: Comparative surveys of caching architecture patterns (proxy/sidecar vs. client library vs. CDN edge vs. managed caching service) and the conditions under which each is the right choice.
• incompleteNo treatment of the social-and-organisational fate of the artefacts themselves. Dependency-cruiser configs, custom coupling-analyser CLIs, and imported Modularity Skill packs are all new load-bearing artefacts. Who owns them? Who updates them when the architecture should change? In the absence of an owner, the rules outlive the intent behind them and become either silently violated or silently obsolete — the classic linter-suppression-debt pathology, scaled to architecture.
  Three more static code analysis sensors — read next: Cutler on institutionalised overload and waste; Fearless Change (Manns & Rising) on what it takes for organisational invariants to survive; Tornhill's Software Design X-Rays on attaching social/ownership data to code-quality signals; Vlad Khononov's modularity work directly (since his Skills are now part of the harness).
• incompleteThe article treats the dependency-cruiser rule set as a substitute for a markdown structure guide, but it skips the question of whether enforcement and explanation are interchangeable. A rule that says 'clients cannot import services' enforces a constraint but does not teach why the layering exists — and the moment the constraint is wrong, the team has no shared prose to reason with. This silently relocates design intent into tooling that few people maintain, and few people can read.
  Three more static code analysis sensors — read next: Ousterhout 'A Philosophy of Software Design' on the role of design documents; Parnas on module specifications; Hickey 'Simple Made Easy' for the distinction between rules-as-policy and rules-as-understanding.
• incompleteHeavy reliance on Khononov's externally maintained Modularity Skills pack as the thing that makes Sensor 3 work. The article does not examine: skill-pack versioning, drift, security/supply-chain assumptions, or what happens when the skill author changes their mind. The harness now has a third-party dependency at the level of taste, not just at the level of code.
  Three more static code analysis sensors — read next: Khononov's Learning Domain-Driven Design and his coupling talks; literature on prompt drift; the emerging 'skills-as-dependency' discussion (Osmani's agent-skills writing).
• incompleteThe coupling-analyser is described as a vibe-coded custom CLI. The article acknowledges it would benefit from suppression of legitimate high-coupling hubs but does not engage with the more interesting question: if your coupling tool requires hand-curated exceptions for every architectural pattern, you are effectively encoding architectural intent in two places (the rules AND the exception list). At that point, why not skip the metric layer and go directly to the inferential review?
  Three more static code analysis sensors — read next: Tornhill, Software Design X-Rays; the dependency-cruiser community's own discussion of when DSM-style tools earn their keep.
• incompleteThe article observes that the AI modularity review found duplicate routes, scattered parameters, and misplaced auth — i.e. exactly the things a senior reviewer would find in a half-hour read of the code. There is no contrastive baseline against human-only review, against pair-review with the original implementing agent, or against a much cheaper rubric like 'review every file changed >X times in the last 30 days'. Without such a baseline, the proposition 'the review is the best available sensor' is unfalsifiable on the evidence given.
  Three more static code analysis sensors — read next: DORA reports' methodology on baselines; Beck on test-commit-revert and 'starving genies' as alternative scaffolds for keeping AI-edited code honest.
• incompleteNo engagement with the relationship between this approach and existing fitness-function / architecture-as-code tooling (ArchUnit, NetArchTest, ts-arch, Modulith, even Structure101). dependency-cruiser is one point in a much larger design space; treating it as 'the' dependency-rules sensor leaves the reader without a sense of where the boundary lies between custom configuration and adopting an established framework.
  Three more static code analysis sensors — read next: Ford/Parsons/Kua 'Building Evolutionary Architectures' on fitness functions (which she links to in the framing); ArchUnit; ts-arch.
• incompleteThe framing assumes the agent is always the implementing actor and the human (plus other agents) are the reviewers. It does not consider the inverse case — where humans implement and the AI modularity review is the rubric against which their code is judged — even though the same tooling would work. This matters because it shapes whether the harness is 'AI guardrails' or 'organisational architecture discipline that happens to use AI'.
  Three more static code analysis sensors — read next: Cutler on operating-system design; Beck on team practices.
• incompleteThe binary 'migrated' metric requires 100% of traffic for 30+ days, but the article never addresses what happens when a fraction of traffic must legitimately stay on the monolith forever (e.g. an old partner integration that will never be upgraded) -- is that endpoint simply never declared migrated, indefinitely, with no path to closing it out?
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for practitioner writing on managing the migration 'long tail' of clients who cannot upgrade -- API deprecation and sunset strategy literature -- to see how others resolve the tension between a strict binary completion metric and an unmigratable minority of traffic.
• incompleteBoth headline numbers -- the ~70% peak-cost savings and the ~50% (4-to-6-hour) upfront tax -- are presented as stable constants across five years, but cloud pricing, wages, and story complexity plausibly shifted substantially between 2021 and 2026; the article gives no methodology or time series, only single-point averages, so a reader cannot tell whether either ratio actually held steady or drifted.
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for any published time-series cost or velocity data from Paycor/Paychex, or for other companies' cost-optimization case studies with longitudinal tracking, to see whether single anecdotal ratios of this kind are durable enough to reuse as planning assumptions.
• incompleteThe architect's function is never defined. The talk asserts that architecture has not changed in its core function, only in practice — but it does not say what the function is. The closest thing to a definition is 'enabling speed and flow via loose coupling and high cohesion', which is more a goal than a function and which collapses architecture into platform engineering in some readings.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Vlad Khononov on coupling in distributed systems; Ruth Malan on architecture as 'the design decisions that are hardest to change'; Team Topologies for the sociotechnical framing Ulseth invokes.
• incompleteVendor positioning is conspicuous: the story is told entirely from the survivors' chair. MobilePay engineers are quoted only as having insisted their tech was 'objectively better', MCash veterans get one similar line, and no failures are attributed to Vipps leadership specifically. The MCash 2017 carve-out is treated as smoothly inevitable; the operational chaos is named ('brannslukningsarbeid') but never traced to a decision.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: MobilePay engineering blog posts from 2023–2024; the Danish fintech press's coverage of the merger; Kristian Pinsel Halvorsen interviews (his name is dropped as the host's 'old boss' from FINN, suggesting a counter-perspective on big-bang migrations in Schibsted/FINN territory)
• incompleteThe role of DNB through the entire history is underexamined. Vipps was DNB's first public-cloud workload, DNB's CEO drove the founding, MCash brought the other Norwegian banks in, and yet the bank-shareholder governance — including how decisions like 'use Vipps's platform, not MobilePay's' actually get taken — is essentially a black box.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Norwegian financial press on Vipps AS ownership changes; Rune Bjerke's memoir/interviews; the prior Heis episode with Kari Olrud Moen (ep 15, 'strategi tydelig og skråsikker') — Moen is Vipps's CEO context
• incompleteTap to Pay is celebrated as a success, but the speakers stop short of explaining what economic margin Vipps captures from international card schemes vs. domestic BankAxept on in-store transactions. Given that the entire European sovereignty argument hinges on dependency on American card schemes, the cost/risk picture matters strategically.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Norwegian card-scheme regulator (Finanstilsynet) cost analyses; EU Digital Markets Act / Payment Services Directive 3 documentation; ECB reports on European payments sovereignty
• incompleteThe 'verb-status' achievement is mentioned but not problematised. Mobilepay is also a verb in Danish; both verbs are now inside one company. What happens to brand neutrality and to user expectations when a Norwegian verb is owned by a Nordic company that wants to be European? The speakers laugh it off ('det tror jeg ikke vi skal prøve å spørre' about Finnish usage).
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Sociolinguistics of brand-verb status; comparable post-merger brand consolidations in payments (Klarna, Wise); MobilePay marketing material from the merger announcement
• incompleteAI in regulated production code is left as an open problem. The 'humanize ser på koden' (humans review code) regulatory expectation is named, but the speakers don't engage with how Norwegian Finanstilsynet, the EU AI Act, or DORA-style governance frameworks will actually treat AI-generated code in financial production.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Finanstilsynet guidance on AI in financial services; EU AI Act high-risk system requirements for payments; DORA 2025 findings on AI-assisted development in regulated industries
• incompleteArchitecture is described as never planned ('aldri hatt et stort arkitekturprosjekt') but the result is a mature multi-cloud, multi-region, regulated platform with 35 product teams and 170+ engineers. The gap between 'we never planned it' and 'we ended up here' is unexamined — what is the actual feedback mechanism that lets a no-architecture-project culture not drift into mush?
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Cutler's writing on emergent architecture and operating-system design; Beck's Tidy First essays on iterative architecture; the prior Heis episode with Greger Teigre Wedel (ep 12, 'når sjefen har svaret') for a Norwegian counter-perspective on top-down architecture
• incompleteThe speakers describe weekly releases and trunk-based-ish development for the app, but back-end deploy cadence and the cross-team coordination model when 35 product teams plus a payments backbone plus an AI platform team all ship at different speeds is not described in detail.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: DORA 2024–2025 reports on deploy frequency and change-failure rate in financial services; NAV's 'fast flow' writeup that Kjetil has already saved (per persona)
• incompleteNo outcome evidence. The piece asserts the product approach is better but supplies zero before/after data — no reduced backlog, no adoption numbers, no user-satisfaction or lead-time improvement. It persuades by resonance with the reader's own pain, not by measured result.
  Shifting Platform Development from Projects to Products — read next: Mik Kersten, 'Project to Product' (value-stream flow metrics); DORA / SPACE for platform outcome measurement; Evan Bottcher, 'What I Talk About When I Talk About Platforms' (Thoughtworks) for how to evidence platform value.
• incompleteThe funding and governance shift is invisible. Moving from project budgets (predictable, milestone-scoped, one-time) to ongoing product funding — and granting the platform team authority to prioritize by aggregate value and to say no — is the real organizational cost of product thinking, and the article never names it.
  Shifting Platform Development from Projects to Products — read next: Mik Kersten, 'Project to Product' (funding argument); Sriram Narayan, 'Products Over Projects' (martinfowler.com); John Cutler on product operating models and how funding shapes behavior.
• incompleteThe piece fuses the mindset shift with one specific cloud-provider architecture (self-service, CRDs, service/control/management planes). It leaves unresolved whether that architecture is a precondition of product thinking, a consequence of it, or merely this team's instance — a lighter platform could adopt product thinking without it.
  Shifting Platform Development from Projects to Products — read next: Skelton & Pais, 'Team Topologies' (platform-as-product and the 'thinnest viable platform'); John Cutler on separating operating model from tooling.
• incompleteThe 'internal customer' analogy is imported without its main caveat: internal customers usually cannot exit or choose an alternative, so adoption can be produced by mandate rather than genuine demand — making adoption a gameable success metric. The captive-customer problem is never addressed.
  Shifting Platform Development from Projects to Products — read next: Marty Cagan, 'Empowered' / 'Inspired' (do product principles hold for captive internal users?); John Cutler on internal platforms and 'build vs. mandate' dynamics.
• incompleteNo deprecation or sunsetting mechanism. The founding complaint is 'accumulated capabilities competing in priority', yet the product model as described adds new abstractions without any account of retiring unused ones — the accumulation problem is diagnosed but structurally left unsolved.
  Shifting Platform Development from Projects to Products — read next: Kent Beck on removing/simplifying (Tidy First? — subtraction as design work); lifecycle/deprecation practices in platform engineering (e.g., Team Topologies on platform evolution).
• 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 the ongoing maintenance cost of pinning specific Triton+vLLM version pairs over time — how often incompatibilities arise, whether security patches lag behind because of pinning, or whether this creates a rolling technical-debt burden as both projects release independently. Relatedly, the article presents the packaging choice (coupling tightness) and engine behavior (pause/resume scheduling) as cleanly separable design axes, but does not explore how often, as in the constrained-decoding case, engine-level behavior ends up leaking into serving-environment-level correctness anyway.
  Netflix Details Its In-House LLM Serving Platform with Triton and vLLM — read next: Technical-debt and dependency-management literature on the costs of pinned version-pair maintenance in fast-moving open-source stacks.
• incompleteThe 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
• incompleteThe organisational shift the article requires but does not theorise. Bricks-not-paths only works in an organisation that has already pushed correctness, security review, cost ownership, and incident response down into stream-aligned teams. In an org where the platform team is also the compliance team and the on-call team, bricks-without-a-path means each stream team must reinvent guardrails. The piece treats this organisational redesign as free — but it is the actual hard part.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Cutler's TBM essays on institutional overload and accountability. Allen Holub's #NoAccountability work. Conway's Law re-readings (Skelton/Pais). Andrew Clay Shafer / DevOps adoption literature on the politics of platform ownership.
• incompleteStrawmanning of the golden path. In Spotify's original formulation and most current usage, a golden path is an opinionated default route through optional tooling — not 'the single way to do things.' Bryant collapses 'golden path' into 'golden cage' to set up the brick contrast, which makes the move feel sharper than it is. The real design choice is the ratio: which bricks ship with reference compositions (paths) attached, and which don't.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: The Spotify Backstage docs on golden paths. The 'paved road' material from Netflix engineering. Honeycomb's writing on opinionated developer platforms.
• incompleteNo treatment of the leaky-abstraction risk that the brick model amplifies. The more composable the platform, the more surface area developers can latch onto — and the harder it becomes to change the implementation later. Bryant raises leaky abstractions as a warning but never connects them to the brick model, which is precisely where they bite hardest.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Spolsky's original 'Law of Leaky Abstractions.' Ousterhout, A Philosophy of Software Design, on deep vs shallow modules — bricks must be deep modules or the abstraction tax is real.
• uninformedNo engagement with the actual maturity literature on internal developer platforms — CNCF Platforms Working Group whitepaper, Team Topologies' Thinnest Viable Platform concept, the platform-engineering maturity model from PlatformCon. The piece treats the field as if Bryant is naming things for the first time.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: CNCF Platforms WG whitepaper (2023+). Team Topologies' TVP material. McKinsey/ThoughtWorks platform engineering reports for the practitioner-economics view.
• incompleteThe claim that C#'s compiler is 'unlikely to ever' gain default acyclic-dependency enforcement is asserted, not argued — especially given the article's own repeated framing that C# has been steadily catching up to F# on feature after feature for over a decade. No reason is given for why this particular feature would be structurally unportable (e.g. because it would be a breaking change to a decade of existing C# codebases) versus merely additive, as most of the other converged features were.
  Worse is better: C# versus F# — read next: Read Seemann's earlier 'C# will eventually get all F# features, right?' (2015, linked in this article) for his own longer analysis of which F# features are and aren't likely to migrate to C#, and check whether dependency-cycle prevention was already flagged there as structurally unportable.
• 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 book repeatedly asserts that layered/technically-oriented architectures are worth their coordination cost 'for small teams' but never quantifies the threshold at which that trade-off flips — the 'Optimize for the Ordinary' aside gestures at the cost without giving any decision procedure for when an organization should migrate from layers to package-by-feature/component or microservices.
  Software Design X-Rays — read next: Look for later work (e.g., Team Topologies, or empirical studies of architecture migrations) that attempts to quantify team-size or coordination-cost thresholds for abandoning layered architectures.
• implicit premiseThe book promotion is structural to the argument — the entire piece is framed to show the book is newly relevant, which may bias the selection and framing of parallels toward ones that support the book's thesis.
  The Organization Is the Bottleneck
• unsupported claimThe 3x shipping speed claim is stated without citation or qualification.
  The Organization Is the Bottleneck
• uninformedWriting in 2018, the piece obviously predates AI coding agents; but its dev and arch criteria (readability, single responsibility, short feedback loops, testability, well-defined interfaces) turn out to be close to exactly the properties later work identifies as what AI agents most need from a codebase to work well — a use case the article had no way to anticipate.
  What good software looks like at REA — read next: Pair with extract-agents-dont-know-what-good-looks-like and extract-software-design-in-the-agentic-age to see how REA's same three lenses would need to change (or wouldn't) if the 'engineer confidently making changes' in the dev-lens question is an AI agent rather than a human.
• 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.