Main idea

A product's complexity is usually read in its code — file sizes, number of layers, dependencies. That is the cheapest part. A shipped feature is then paid for by the user who has to work out what it is for, in the support tickets it opens, in the documentation that has to be written and maintained, in the coherence of an experience that blurs with every addition, and in the organization's ability to explain what it is building.

Those items don't accelerate. When the code becomes the fast link, the bottlenecks move to review, security, functional scoping, integration and human absorption — which become even more critical than before, since they receive more.

So a product becomes unreadable, for its users as much as for its teams, as soon as features are added faster than their usage is understood. Producing more code isn't producing more value; it is moving the bill to departments that never provisioned for it.

Why it matters

This changes what you count when you arbitrate an addition. The development cost, now low, stops being an indicator of total cost, and an estimate that stops at the code systematically understates what a feature commits you to.

It also gives support and documentation the status of an early warning: they are the first places where a complexity decided elsewhere becomes measurable.

Nuances and limits

Not all complexity is borne by the user. An invisible feature, on by default and with no surface of use, can weigh the code down considerably without costing anything in adoption or support — the bill stays whole, but inside the team.

And the reasoning has a boundary: an organization that only shipped what support could absorb effortlessly would ship little, and would leave a competitor to take the ground. The question is provisioning, not abstention.

Open questions

• How do you estimate a feature's adoption and support load before shipping it, other than by observing after the fact the tickets it generates?