Complexity Protects Itself

By Jory Pestorious | April 2026

The Pattern

Netscape spent nearly three years between major browser releases while it rewrote the codebase. Joel Spolsky wrote that its market share plummeted during that gap. He called a rewrite from scratch "the single worst strategic mistake that any software company can make" because the working code held years of fixes and production knowledge that the replacement had not earned yet. The old code was ugly. It worked.

That does not mean every rewrite fails or every custom platform is a mistake. I care about a narrower pattern: a working path is replaced before the team understands its constraints, and the replacement gathers more responsibilities as it grows. It may look cleaner while becoming more coupled/fragile. The question is whether that new ownership solves a product problem worth owning.

G.K. Chesterton described the first test in 1929: before removing a fence or gate across a road, understand why it was put there. In software, the fence may be an awkward branch, duplicated check, or boring service that already encodes a failure the replacement has not seen.

Fred Brooks described the ambition that follows. He called it the Second System Effect: the architect of the first system, having been restrained by budgets and deadlines, pours the deferred ideas into the second. "The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one."

Dan McKinley asks readers to imagine that a company gets about three innovation tokens. He calls the number approximate, a way to describe limited attention rather than a measured budget. Spend those tokens on a novel database, deployment system, and secrets layer, and the team must learn how each fails while it is also trying to build the product. Spend all three, and even an outage can become a research project.

What Gets Complected

Rich Hickey's "Simple Made Easy" gives the mechanism a name. Hickey contrasts simplex, one twist, with complexus, braided together, and uses complect for concerns that have been interleaved. Simple and easy are different properties: easy is familiar to a person, while simple describes a system whose concerns are not intertwined. A complected system can feel easy to its builders because they already carry the missing context.

A deployment platform might handle infrastructure state, secrets, CI orchestration, tenant configuration, and approvals in one codebase. Putting them together expands what an engineer must understand and change at once. Narrower tools can shrink that reasoning boundary even when they still depend on one another at runtime.

Sandi Metz reached the same problem through abstraction: "Duplication is far cheaper than the wrong abstraction." A unified platform may remove duplicated code, then recover every real difference through another conditional. Each exception makes the shared abstraction harder to change than the separate code it replaced.

Each conditional also increases how much of the system the team must hold in mind. Margaret-Anne Storey applied the existing term cognitive debt to software teams in February 2026: system complexity can grow faster than the team's understanding of it. Addy Osmani calls the related gap comprehension debt, especially when AI increases the amount of code faster than anyone can explain it.

Stress Exposes the Ownership Model

Nassim Taleb's Antifragile distinguishes systems that are harmed by stress, resist it, or gain from it. That taxonomy does not make a managed service antifragile or an internal platform fragile by definition. Whether either system gets stronger depends on what happens after a failure.

A managed service can improve when customer incidents become tested fixes for every tenant, but it can also spread one defect across them. An internal platform can improve if incidents produce structural checks, shared documentation, and ownership that survives the original team. It becomes fragile when each incident adds another exception while the required context concentrates in fewer people.

Brooks's communication formula helps explain one part of that risk. A team of n people can have n(n - 1) / 2 pairwise communication channels, so ten people can have 45 and one hundred can have 4,950. The formula describes pairwise coordination, not whether a one-person system can transfer knowledge. A bus factor of one becomes dangerous when that person's context is not documented or shared.

The Visible Ops Handbook cites Gartner analysis that 80 percent of unplanned downtime came from people and process issues, including poor change management. That figure does not measure opacity. My concern is that opaque systems give reviewers less chance to see the effect of a change and responders fewer ways to recover without the original author.

The 2024 DORA report also undercuts the idea that slower change is automatically safer. Its elite cluster deployed on demand, reported a 5 percent change-fail rate, and recovered from failed deployments in under an hour. Its low-performing cluster deployed between monthly and twice yearly, reported a 40 percent change-fail rate, and recovered in one week to one month. The report does not blame complexity for the gap. It does show that the low-performing cluster delivered less often and was not safer.

Before You Build It

Before building a deployment platform, I want one question answered: who already built the parts we would now own? Products such as Spacelift, GitHub Actions, and Terraform already cover parts of that stack. None is automatically the right fit. A custom build should still name the product-specific requirement those options cannot meet, along with the failures and maintenance the team is choosing to absorb.

Dan Luu's case studies of billion-dollar companies with comparatively simple architectures are a useful counterweight to the assumption that growth automatically demands a platform. Scale can justify custom infrastructure, but it does not do so by itself.

For a company whose product is not infrastructure, I would require a concrete advantage before spending scarce engineering attention on it. Charity Majors calls developer cycles the scarcest resource in a company, so outsourcing infrastructure can keep them on the product. A vendor may amortize reliability work across customers, but the team still has to verify that the vendor's incentives and boundaries match its own.

AI lowers the cost of starting a build while leaving the team responsible for maintaining the result. In a 2025 randomized trial, 16 experienced open-source developers completed 246 tasks in mature repositories they knew well. With early-2025 AI tools, they took 19 percent longer while estimating that AI had made them 20 percent faster. METR warns against generalizing beyond that setting, and later tools may behave differently. The result still gives me a reason to measure the maintenance cost instead of assuming generated code removed it.

The 2025 DORA report describes AI as an amplifier of organizational strengths and weaknesses. DORA uses a different capability set than Hickey, but the finding gives me a practical check: is AI accelerating a system with clear boundaries and executable checks, or merely producing more code around an unclear one?

Kelsey Hightower put the social cost plainly: "We tend to build overly complex solutions and dedicate our careers justifying their existence." Once a platform becomes the path to production, replacing it can threaten the work, status, and routines built around it. That is one way complexity starts protecting itself.

Convention and Structure

In Verified Context Is the Moat, I argued that a rule people must remember is weaker than one the system enforces. Consider a deployment pipeline where every code path must call a function that injects required configuration. The rule can be documented and understood, yet one missed call still ships a deployment without the configuration.

Now change the design so every deployment is validated for required variables before it can proceed. The implementation could be custom or managed. What matters is that the invalid state is rejected at the boundary instead of relying on every caller to remember the rule.

I see a related asymmetry between protection and verification in the agent experiments I wrote about earlier. Those experiments produced protection mechanisms without spontaneous verification. In an organization, sunk cost and operational dependency protect a platform automatically; checking whether it still earns its cost takes deliberate work.

Three Tests

Does more stress make this stronger? Name what changes after an incident. Tested fixes and shared context can strengthen the system; another undocumented exception and narrower ownership make it more fragile.

What am I braiding together that should be separate? List the concerns that must be understood or changed together. If a secrets change requires tracing provisioning, tenant configuration, CI, and approvals, the reasoning boundary is already too wide.

Who already solved this? List the managed and open-source options, then state the exact product requirement each one cannot meet. "More flexibility" is not enough unless the team prices the ownership that flexibility creates.

A custom platform can pass all three tests, and when it does, build it with explicit ownership. Without those answers, do not let it become the only path to production.

Sources

Foundational

Chesterton, G.K. (1929). The Thing, "The Drift from Domesticity." The fence or gate example and the requirement to understand a structure before removing it.

Brooks, F. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. The Second System Effect and pairwise communication channels.

Hickey, R. (2011). "Simple Made Easy." Strange Loop Conference. Simple versus easy and the cost of complecting concerns.

Taleb, N.N. (2012). Antifragile: Things That Gain from Disorder. Random House. Fragile, robust, and antifragile systems.

Software Engineering

Spolsky, J. (2000). "Things You Should Never Do, Part I." Joel on Software. Netscape's rewrite and the production knowledge held in old code.

McKinley, D. (2015). "Choose Boring Technology." Innovation tokens and the operational cost of novelty.

Metz, S. (2016). "The Wrong Abstraction." "Duplication is far cheaper than the wrong abstraction."

Luu, D. (2022). "In Defense of Simple Architectures." Case studies of billion-dollar companies running on comparatively simple technical foundations.

Data and Reports

DORA Team, Google Cloud. (2024). Accelerate State of DevOps Report. Software delivery performance clusters and their throughput and stability measures.

DORA Team, Google Cloud. (2025). State of AI-Assisted Software Development. AI as an amplifier of existing organizational strengths and weaknesses.

METR. (2025). "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." A randomized trial of 16 experienced developers completing 246 tasks in familiar open-source repositories.

Kim, G., Behr, K., & Spafford, G. (2004). The Visible Ops Handbook. People, process, and change-management sources of unplanned downtime.

Complexity and Cognitive Load

Storey, M.-A. (2026). "Cognitive Debt." Applying cognitive debt to the gap between software complexity and team understanding.

Osmani, A. (2026). "Comprehension Debt." The gap between code volume and human understanding.

Industry Voices

Hightower, K. (2019). "We tend to build overly complex solutions and dedicate our careers justifying their existence."

Majors, C. (2022). "The Future of Ops Is Platform Engineering." Developer cycles as a scarce resource and the case for outsourcing infrastructure.

Grugbrain.dev. (2022). "The Grug Brained Developer." A developer-voice treatment of complexity, Chesterton's Fence, and premature abstraction.