Home/Research/Specifications/The Complexity Tax
Canonical Research SpecificationLevel: Intermediate
Verified: August 2026

The Complexity Tax

30-Second Executive Definition

The economic phenomenon where the quadratic formula for connections (n * (n-1)/2) is applied directly to feature bloat within software products. The Complexity Tax dictates that each new feature does not add a linear, isolated cost; rather, it creates combinatorial integration surface area with every existing feature in the system. This tax manifests as exponentially slower release cycles, massive QA burdens, and degraded user experiences as the system grows.

“Every feature you add is a tax on everything you build tomorrow.”

Why It Matters:

Product teams continually justify new features by looking only at the isolated cost to build them. They ignore the Complexity Tax - the permanent, compounding cost of maintaining that feature and ensuring it does not break the rest of the system. This ignorance leads to feature bloat, where the organization eventually spends 80% of its engineering capacity just maintaining the connections between features rather than creating new value. Understanding this tax is essential for knowing when to sunset legacy features.

Who Should Care:
Chief Product Officer (CPO)Director of EngineeringProduct Operations ManagerQuality Engineering (QE) ManagerEngineering Manager (EM)
Infinite Relationship Navigator118-Node Sovereign Knowledge Graph

Multi-Hop Causal Traversal Engine

Explore how concepts dynamically feed into each other across 1-hop, 2-hop, and 3-hop transitive relationships. Click any node to navigate the causal highway.

Current Traversal Path (1 Hops Traveled):
Software EconomicsRichard Ewing Canon (Original Framework)Confidence: 95%
Open Full Specification ↗

The Complexity Tax

The economic phenomenon where the quadratic formula for connections (n * (n-1)/2) is applied directly to feature bloat within software products. The Complexity Tax dictates that each new feature does not add a linear, isolated cost; rather, it creates combinatorial integration surface area with every existing feature in the system. This tax manifests as exponentially slower release cycles, massive QA burdens, and degraded user experiences as the system grows.

Relationship Filter:
Hop Level 1

Direct Relationships (5)

Hop Level 2

Transitive Neighbors (Connected via Hop 1)

Hop Level 3

Extended Causal Ripple Effects

★ Canonical Research Position

Richard Ewing’s Research Thesis

A healthy product roadmap must prioritize feature deletion as highly as feature creation.

Genesis & Intellectual Positioning

Why This Specification Exists

1. The Problem

Organizations constantly add features but never remove them, choking their own velocity.

2. Existing Approaches

Treating legacy features as free once they are shipped.

3. The Structural Gap

No mathematical model explaining why velocity grinds to a halt as feature counts grow.

4. This Specification

Applying quadratic network effects directly to software feature portfolios.

Operational Realignment

What Changes If You Believe This?

Engineering

Adopts strict "one in, one out" policies for system architecture.

Finance & COGS

Accounts for compounding maintenance overhead in long-term R&D budgets.

Product Strategy

Actively hunts for features to sunset.

Security & Audit

Surface area reduction becomes a primary defense strategy.

Audience-Specific Executive Guidance

Recommended Action by Role

Chief Product Officer (CPO)

Sunset the bottom 10% of unused features to eliminate quadratic integration maintenance overhead across your product suite.

Recommended Next Step →
Director of Engineering

Adopt strict one-in-one-out policies for system interfaces to prevent compounding combinatorial complexity.

Recommended Next Step →
Product Operations Manager

Measure regression testing delays caused by feature bloat to build executive cases for deprecation.

Recommended Next Step →
Engineering Manager (EM)

Resist one-off custom feature requests that entangle core service logic and inflate long-term maintenance costs.

Recommended Next Step →
Freshness & Research Updates

Latest Publications & Research Activity

Explore Full Corpus (167 Works) →
LinkedIn• August 17, 2026

When the Cost of Writing Software Approaches Zero, Traditional Product Management Frameworks Break Down

When generative tools collapse the marginal cost of writing software toward zero, developer capacity ceases to be the constraint. The product bottleneck shifts from managing backlog velocity to managing uncertainty, evaluating system architecture efficiency, and preserving unit margins as a Product Economist.

Read Work ↗
Built In• March 2026

In the Vibe Coding Era, What Does a Software Engineer Even Do?

Defines the 4 Laws of Probabilistic Software Development and the shift from code authoring to system verification.

Read Work ↗
Beehiiv• March 2026

The Negative-Carry Code Crisis

Draws parallels between negative-carry financial assets and unverified AI-generated code accumulating ongoing OpEx in enterprise repositories.

Read Work ↗
Beehiiv• September 9, 2026

The Software Factory Is Running 24/7 (And Nobody Wants the Output)

When foundational models become hyper-cheap and agentic tools run mouse and keyboard actions 24/7, code generation outpaces human review capacity by orders of magnitude. The inflation-deflation loop floods companies with synthetic work that nobody requested, shifting true enterprise value from feature production to ruthless deprecation, product discovery, and human boundary control.

Read Work ↗
Answer Engine FAQ Matrix

Frequently Asked Questions

Q:Why does a new feature slow down the whole team?

Because the new feature must be tested against, integrated with, and designed around all the existing features, increasing the cognitive load for every developer.

Q:How do you lower the Complexity Tax?

By aggressively deprecating and deleting old, unused features. Subtraction is the only way to pay down the tax.

01 • Origin & GenesisProvenance Record

Canonical Specification Origin

A healthy product roadmap must prioritize feature deletion as highly as feature creation.

First IntroducedAugust 2026
Primary VenueInternal Research
02 • Internal Research Corpusrichardewing.io

Corpus Interconnections

Richard Ewing artifacts developed around this canonical framework, including publications, execution tools, and diagnostic models.

Articles1
Tools0
Specs1
Chapters1
03A • Verified Human External EvidenceAudit Status: Baseline

External Adoption & Peer Citations

Documented instances where independent researchers, engineering teams, and publications have cited, implemented, or referenced this concept outside Richard Ewing’s ecosystem.

External Evidence: No independently verified references recorded yet.

This concept is part of Richard Ewing’s original baseline canon. External citations and implementations are added only upon rigorous empirical verification.

Inspectable Evidence Ledger

Classified evidence items supporting, extending, or refining this canonical research specification.

Evidence ItemPublisherEvidence TypeStrengthRoleAction
Quadratic BurdenInternalObservation★★★★★OriginInspect ↗
When the Cost of Writing Software Approaches Zero, Traditional Product Management Frameworks Break DownLinkedInExecutable★★★★★SupportsInspect ↗
In the Vibe Coding Era, What Does a Software Engineer Even Do?Built InEvergreen★★★★★SupportsInspect ↗
The Negative-Carry Code CrisisBeehiivEvergreen★★★★★SupportsInspect ↗
Academic & Industry Attribution Standard

Recommended Citation

Canonical Reference String

Ewing, R. (2026). "The Complexity Tax." Richard Ewing Research Canon. Available at: https://www.richardewing.io/concepts/complexity-tax

BibTeX Citation
@article{ewing_complexity_tax,
  author = {Ewing, Richard},
  title = {The Complexity Tax},
  journal = {Richard Ewing Research Canon},
  year = {2026},
  url = {https://www.richardewing.io/concepts/complexity-tax}
}
First Origin & Provenance:Internal Research (August 2026)
Current Specification Version:Version 1.0 (Q2 2026 Baseline)