Chapter 13 — The Economics of Living Software

There is a number that runs the software industry, and it has never once appeared on a keynote slide. It is the fraction of a software system's lifetime cost that goes to maintenance — not to building the thing, but to keeping it, changing it, and living with it afterward. The research on this question goes back to the late 1970s, and while the figures vary by study and by decade, the range is remarkably stable: most published estimates put maintenance somewhere between 60 and 80 percent of total lifetime cost, and some respected surveys have run higher. Whatever the exact number, the direction has never been in dispute. Building the software is the cheap part. The expensive part is everything after.

And inside that expensive part hides a stranger number still. When researchers have broken maintenance down into its activities, the largest single component — by most estimates, around half of maintenance effort — is not writing the fix. It is comprehension: programmers reading code, tracing calls, and running experiments to rediscover what the system does before they dare to change it. Think about what that means at industry scale. The dominant cost of the most valuable industry in history is the cost of re-learning decisions the industry already made. We wrote it down once, in the one language guaranteed to become unreadable, and now we pay — perpetually, at engineering salaries — to re-derive our own conclusions. If a manufacturing company spent the majority of its budget re-discovering how its own factories worked, we would not call that maintenance. We would call an ambulance.

This chapter is about what happens to the money when that stops. I will build the cost structure of code-era software from the ground up, show which parts of it a semantically closed application removes and why, and then — clearly flagged as projection — follow the consequences out into the industries, pricing models, and labor markets that are currently organized around the old cost structure. The mechanism exists and ships today. The macroeconomics are a forecast, and I will mark them as such.

The anatomy of the bill

Take an enterprise application of consequence — a policy administration system, a billing platform, an order-management backbone — and itemize what it actually costs across its life. Four lines dominate the bill, and all four grow from the same root.

Comprehension cost. This is the tax described above, and the crucial fact about it is that it rises with age. Chapter 1 laid out Naur's argument, so I will invoke it rather than repeat it: the working theory of a program lives in its authors and evaporates as they leave, and once the theory is gone, every change begins with archaeology. A young system with its original team changes cheaply. The same system a decade later — same code, same behavior — costs multiples more per change, purely because nobody remembers why it is the way it is. No other capital asset behaves like this. A drill press does not become harder to understand because the machinist retired. Software is the only major asset class that depreciates by forgetting.

Change-risk cost. Because nobody fully understands the system, every change carries a probability of breaking something unrelated, and the enterprise pays to manage that probability: regression suites, staging environments, release trains, change-advisory boards, the padding that engineers quietly add to every estimate because they have been burned before. Notice that most of this apparatus is not the cost of making changes. It is the cost of fear — insurance premiums against a blast radius nobody can compute. And the premium rises with age too, because the blast radius widens as the theory shrinks.

Coordination cost. Chapter 1 called the narrow set of people who can read the code the aperture, and the aperture is expensive far beyond its payroll. Every change request must queue for it: the backlog, the tickets, the grooming sessions, the meetings where people who understand the business explain what they want to people who understand the code, in a lossy verbal protocol, repeatedly. An enterprise with a thousand ideas and an aperture of five engineers is paying for a thousand ideas and getting fifty — the other nine hundred and fifty silently expire in the queue, which is an opportunity cost no ledger records.

The rewrite. And then, every ten or fifteen years, the accumulated illegibility is settled in a single balloon payment. Chapter 1 walked through the ritual; here I only want to book it correctly. A rewrite is not an investment in new capability — the business case is almost always "we can no longer change the old system safely." It is the periodic capital destruction of an asset that decayed, plus the purchase of a younger asset made of the same decaying material. Accountants amortize software over five years or so, which is a polite fiction; engineers know the asset starts depreciating at the first standup. The rewrite is where the fiction gets marked to market.

Sum the four lines and the shape of the paradigm's economics becomes visible: a modest construction cost followed by decades of compounding payments, nearly all of which trace back to a single defect — the authoritative description of the product became unreadable, and everything else is the interest on that debt.

The inversion

Now run the same four lines against an application whose definition is governed data — the substrate of Part II, operated by the loops of Part III. I will keep the register honest: everything in this section describes mechanism that ships today, in the worked example and in anything built to the same shape. What it adds up to at industry scale comes later, flagged.

Comprehension cost collapses. In a semantically closed application, the description of the product is not smeared across a codebase; it is a graph of typed, linked objects — pages, workflows, policies, connections, knowledge — that a machine can traverse in milliseconds and a human can query in plain language. "What does this system do when a claim exceeds the threshold?" stops being a three-week archaeology project and becomes a question the system answers about itself, with references. The theory that Naur said could not be written down still cannot be — but vastly more of what maintenance programmers actually spend their hours rediscovering (what exists, what touches what, what changed, when, and by whose approval) is now first-class, structured, and current, because it is the very thing the system executes. There is no second description to drift. The reading tax does not fall to zero; it falls from the dominant line item to a rounding error.

Change-risk cost falls with it. A change to a semantic application is not a deployment; it is a governed data mutation — drafted as an object, reviewed against policy, versioned on landing, reversible by moving a release pin back. Chapter 9 established the machinery, so I will simply point at its economic meaning: nearly everything the enterprise spends on change fear — the boards, the freezes, the padded estimates — exists because code-era changes are irreversible in practice and unbounded in blast radius. Make every change a draft with a diff and a rollback, and the insurance premium collapses. You still test. You still gate what matters. But you gate with mechanisms, not meetings.

Maintenance begins to do itself. The healing loop of chapter 10 is, economically speaking, the automation of toil: the drift suite scans the product because the product is data, opens Issues as formal objects, and repairs what policy allows — deterministically where possible, with escalation where it must. The interesting line in the ledger is not that the machine fixes things; it is that an entire category of human labor — the routine, low-judgment maintenance that pads every enterprise's run-rate — converts from salary to compute, with an audit trail the salary never produced.

And the rewrite disappears as a category. This is the deepest cut, and the mechanism is chapter 11's evolution loop: stakeholder intent lands as a Goal, becomes a reviewed Change request, becomes a governed build that mutates the product graph under version control. An application that absorbs change continuously never accumulates the illegibility that justifies demolition. There is no balloon payment because the debt is serviced on every change — or more precisely, because the debt is never issued. When the next paradigm shift arrives, it lands as new object types and new workflows, not as a new codebase. Replacement becomes absorption, and the industry's largest recurring capital expense simply has nothing to attach to.

Set the two cost structures side by side and the shape of the inversion is hard to miss:

Every row of the left column compounds against the owner. Every row of the right column is either flat or compounds for the owner. That asymmetry, more than any single feature, is the economic content of semantic closure.

Following the money

Here the register changes, and I want to be explicit about it: what follows is projection — full Kurzweil, as promised for this part of the book. The mechanism above ships. The consequences below are where I believe the mechanism leads, if the paradigm holds and the installed base begins to turn over. Hold me to the reasoning, not to the timetable.

The modernization industry loses its renewable crop. A very large fraction of global IT services revenue — analysts size the application-modernization market alone in the tens of billions of dollars a year, and the broader legacy-maintenance economy far higher — is, in effect, the rewrite ritual sold as a practice area. It is a renewable crop: every modernization delivers a new system that will itself require modernization in fifteen years, which is a magnificent business model for everyone except the client. If absorption replaces replacement, that annuity breaks. The revenue does not vanish overnight — the next decade will likely see a boom in transition services, the one-time work of extracting product descriptions from code-era estates into governed graphs — but transition is a harvest, not a crop. A services industry built on the recurrence of illegibility will need a new recurrence, and I suspect it will find one in governance: someone must operate the gates, tune the policies, and own the audit. The consulting engagement of 2035 looks less like "rebuild your claims system" and more like "run your product's constitution."

Per-seat pricing loses its floor. SaaS pricing rests on an unspoken premise: the product is frozen by the vendor, evolving it is expensive, and therefore customers rent access to the vendor's roadmap. When a product is cheap to evolve and expensive only to govern, that premise inverts. If the paradigm holds, pricing gravitates away from seats and toward the things that remain scarce — governed capacity for change, quality of the substrate, liability for the gates. The moat stops being switching cost (your data hostage in our schema) and becomes graph quality: the vendor with the richest, best-governed product graph can evolve fastest under the strictest gates. That is a healthier moat, and a more honest one.

Build-versus-buy stops being a dilemma. The old calculus was grim on both branches: build meant owning the decay curve described above; buy meant adopting a frozen roadmap and paying rent on your own requirements backlog. A semantic application splits the difference out of existence. "Buying" becomes installing a governed, evolvable product graph — the worked example ships this shape as installable packs — and then evolving it yourself, under your own gates, at product speed. You get the vendor's head start and the builder's sovereignty. The enterprises that understand this first will, I project, stop asking "build or buy?" and start asking "whose substrate, and who holds the pen?"

And the labor market re-prices. Chapter 12 made the argument about authorship, so I will not repeat its machinery — only its economics. When the writing of descriptions is abundant (models write them by the token) and the governing of descriptions is scarce (someone must decide what ought to change, review what the machine proposes, and answer for what lands), wages follow scarcity. Demand shifts from the people who could type the change to the people who can be accountable for it. The aperture does not merely widen; it changes profession.

The asset flip

All of which converges on the thesis of this chapter, and it is worth stating as bluntly as accounting allows.

Code-era software is a liability wearing an asset's clothes. It appears on the balance sheet as capitalized development, but its economic behavior is a liability's: it decays, it demands compounding payments to hold still, its legibility — the very property that makes it changeable — evaporates on a schedule set by employee tenure, and every fifteen years it presents a demolition invoice. The industry has always known this in its bones; that is why "legacy," which in every other field means inheritance, in software means the thing we are afraid of.

A semantically closed application has the opposite sign. Every healed Issue leaves the graph more conformant than before. Every absorbed Goal leaves it more capable. Every recorded Event enriches the organizational memory that grounds the next decision, and every governed change lands as versioned, auditable structure rather than as sediment smeared across a codebase. Age improves it, because improvement accretes as data instead of decaying as theory. Its tenth year is more legible than its first — the exact inversion of every codebase I have ever inherited. If the paradigm holds, software becomes what the balance sheet always pretended it was: an asset that compounds, whose owner keeps the compounding.

I do not want to oversell the symmetry — a product graph can still encode bad decisions, and governance can still approve nonsense faster than committees ever managed. But the direction of drift flips, and in economics, direction is destiny.

What could keep this from happening

Confidence is not salesmanship, and a forecast that cannot name its failure modes is a pitch. Three things could keep these economics from materializing, and each deserves to be stated plainly.

Governance could become the new bureaucracy. The gates of Part III are the paradigm's entire claim to safety, and gates have a natural tendency to multiply. It is entirely possible to build a semantic application whose change requests queue behind approval workflows slower than the old backlog ever was — the aperture reconstituted as a committee, with better audit trails. The economics above depend on governance being proportionate: tiered autonomy for the routine, human judgment reserved for the material. Organizations that gate everything will discover they have paid for a living application and put it in a coma. The mechanism permits proportionate governance; it cannot compel it.

The platform trap could reproduce at a higher level. If product graphs are proprietary — if the description of your product is legible only to one vendor's runtime — then the industry will have traded code lock-in for graph lock-in, and much of the build-versus-buy argument above collapses back into rent. The honest answer is that this risk is real and its resolution is not yet history: it depends on representations staying open and graphs staying exportable, and the commercial pressure will not always point that way. The paradigm's economics require the description to belong to the enterprise it describes. Whether the market enforces that is a fight, not a foregone conclusion.

And the installed base does not close itself. Nobody semantically closes a 1974 COBOL accrual program by wishing. The world's existing estate — those couple hundred billion lines from chapter 1 — holds its product descriptions hostage in exactly the form the paradigm exists to escape, and extracting them is real work: part automated translation, part archaeology, part admitting that some of what the old system does, nobody wants written down. The transition economics only clearly favor the paradigm for new construction and for the systems already facing a rewrite anyway — which, given the demographics of the estate, is a larger market every year, but is not the whole market. The last COBOL program will outlive this book, and probably its author.

None of these strike me as fatal. All of them strike me as the actual terrain — the difference between a mechanism that works and an economy that reorganizes around it.

The point

Software's true cost structure has always been dominated by what comes after the writing: comprehension that grows dearer as theory evaporates, change made expensive by fear, coordination throttled through the aperture, and the periodic capital destruction of the rewrite — all interest on one debt, the unreadable description. A semantically closed application retires that debt at the source: the description is structured data the system can answer questions about, changes are governed mutations with rollback rather than deployments of fear, routine maintenance converts from salary to governed compute, and absorption replaces replacement, deleting the rewrite as a category. If the paradigm holds, the consequences run deep: modernization loses its annuity, pricing migrates from seats to governance, build-versus-buy dissolves into substrate sovereignty, and software flips from a liability that decays into an asset that compounds. The mechanism ships today; the macroeconomics are a projection, and their failure modes — bureaucratic gates, graph lock-in, the stubborn installed base — are real. But the direction of drift reverses, and everything else in this chapter is arithmetic on that reversal.