Large Software Is Not Built Like a Building. It Grows Like an Organism. And It Rots.

Somewhere in a bank, there is a COBOL program that processes your credit card transactions. It was written in the 1960s or 1970s by a programmer who has long since retired or died. It has been modified thousands of times by hundreds of different programmers over six decades. No single person alive today understands the entire program. No complete documentation exists. Parts of the code are commented in abbreviations that no current employee can decipher.

It processes 95% of ATM transactions in the United States.

It works. Nobody dares touch it.

This is not an edge case. This is the normal condition of large-scale software. The systems that run the modern world — banking, aviation, telecommunications, healthcare, logistics, power grids — are held together by code that has grown beyond any individual's comprehension, maintained by teams who understand their own small section and pray that their changes do not break someone else's.

“Software does not age like buildings. Buildings get weaker at the foundations. Software gets weaker everywhere, simultaneously, in ways nobody can see.”

This is software entropy. And it is as inevitable as the thermodynamic kind.

ROOT — THE SOFTWARE CRISIS THAT NEVER ENDED

In October 1968, a group of computer scientists gathered in Garmisch, Germany, for a conference organized by NATO's Science Committee. The topic was the state of software development, and the consensus was alarming.

Software projects were chronically over budget. They were consistently delivered late. They were riddled with bugs. As computers grew more powerful and software grew more ambitious, the gap between what software was supposed to do and what it actually did was widening. The attendees coined a term for this phenomenon: the software crisis.

The crisis had a simple root cause: software complexity was growing faster than the human ability to manage it. A program with 100 lines of code is comprehensible to one person. A program with 10,000 lines requires careful organization but is manageable. A program with 1 million lines exceeds any individual's cognitive capacity. By the late 1960s, military and corporate software projects were routinely reaching millions of lines, and the tools and methods for managing that complexity did not exist.

Edsger Dijkstra, one of the most influential computer scientists of the 20th century, articulated the problem with characteristic bluntness. In various papers through the 1970s, he argued that the difficulty of software was not a temporary problem to be solved by better tools or better training. It was an inherent property of the medium. Software is, by its nature, the most complex artifact humans create — not because individual lines are hard to write, but because the interactions between lines grow exponentially with the size of the program.

Fred Brooks, who managed the development of IBM's OS/360 (one of the largest software projects of the 1960s), published "The Mythical Man-Month" in 1975. His central observation: adding more programmers to a late software project makes it later, because the new programmers must be trained, communication overhead increases, and the additional complexity of coordinating more people outweighs their productive output.

“The most dangerous code in the world is code that works. Nobody refactors code that works. So it sits there, gathering complexity, until it becomes load-bearing and irreplaceable.”

This was 1975. The observation remains true in 2026.

THE LIFE CYCLE OF CODE ROT

Fresh code is clean. A new project, started by a small team with a clear specification, produces code that is organized, readable, and elegant. The architecture makes sense. The naming conventions are consistent. The team understands every part of the system because they wrote it.

Then the project succeeds. And success is what kills the code.

Success means the software is deployed to real users. Real users discover edge cases. Edge cases require patches. Patches are written under time pressure. Under time pressure, programmers take shortcuts. Shortcuts work in the moment but create dependencies and side effects that are not documented. The shortcut becomes permanent because it works and nobody wants to risk breaking it by cleaning it up.

Ward Cunningham, the inventor of the wiki, gave this phenomenon a name in 1992: technical debt. The metaphor is financial. When you take a shortcut in code, you are borrowing against the future. The shortcut is the principal. The ongoing cost of working around the shortcut — the extra time, the extra bugs, the extra complexity — is the interest. If you pay it back quickly (by refactoring the shortcut into proper code), the cost is small. If you let it compound, the interest eventually exceeds the principal.

Most organizations let it compound.

DID YOU KNOW?

Google maintains one of the largest codebases in human history: over 2 billion lines of code stored in a single monolithic repository called "google3." Approximately 25,000 engineers make changes to this repository every working day. Google has built custom tools — Blaze (build system), Critique (code review), and Piper (version control) — specifically to manage the complexity. Despite these tools, Google engineers frequently describe encountering code written by teams that no longer exist, serving purposes that are no longer relevant, with dependencies that are no longer maintained. The code works. Nobody knows exactly why. Removing it would require understanding its full dependency graph, which nobody has time to trace.

THE TURNOVER PROBLEM

Code rot accelerates when people leave.

In a typical technology company, the average tenure of a software engineer is 2 to 3 years. This means that the person who wrote a piece of code is likely gone before the code's first major bug surfaces. The person who replaces them inherits the code without the context that produced it. They can read what the code does (if it is well-written) but not why it does it. The rationale — the constraints, the requirements, the trade-offs, the bugs that were tried and rejected — lives only in the head of the person who left.

Over time, a codebase accumulates layers of decisions made by people who are no longer available to explain them. Each layer is functional but opaque. The new engineers add their own layer on top, working around the parts they do not understand rather than modifying them. The codebase grows vertically — new functionality stacked on old — rather than being restructured horizontally.

This is how a codebase becomes "spaghetti code": not through incompetence, but through the natural accumulation of reasonable decisions made by a rotating cast of engineers, each of whom understood their own contribution but not the whole.

THE COBOL PROBLEM

The most extreme example of code rot is COBOL.

COBOL (Common Business-Oriented Language) was designed in 1959 by a committee that included Grace Hopper. It was intended for business applications: payroll, accounting, banking. It was wordy by design — the syntax reads almost like English — because the designers wanted the code to be readable by non-programmers, specifically business managers.

COBOL worked well. Banks adopted it. Governments adopted it. Insurance companies adopted it. By the 1970s, COBOL was the dominant language for business computing. Billions of lines were written.

Then the world moved on. C, Java, Python, JavaScript — newer languages with modern features, better tooling, and larger communities replaced COBOL for new development. But the old COBOL code did not go away. It could not go away. It was running the transaction processing systems that banks depend on. Replacing it would mean rewriting decades of accumulated business logic — logic that nobody fully documents because the COBOL code is the documentation.

Today, an estimated 220 billion lines of COBOL are in active production. COBOL processes 95% of US ATM transactions, 80% of in-person transactions, and a significant portion of government benefits processing (Social Security, Medicare, state unemployment systems).

The average COBOL programmer is over 55 years old. There are fewer than 1,000 active COBOL developers under 40 in the United States. Universities stopped teaching COBOL decades ago. When these programmers retire, their knowledge of the systems they maintain retires with them.

During the COVID-19 pandemic in 2020, state unemployment systems built on COBOL crashed under the surge of claims. New Jersey's governor publicly pleaded for volunteer COBOL programmers. The systems were not failing because COBOL is a bad language. They were failing because nobody understood the code well enough to modify it quickly.

THE ENTROPY EQUATION

Software entropy is not a metaphor. It is measurable.

Lehman's Laws of Software Evolution, formulated by Meir Lehman in the 1970s through the 1990s, describe empirically observed patterns in how large software systems change over time. The most important law: the complexity of a software system increases over time unless active work is done to reduce it. Left alone, every addition — every new feature, every bug fix, every integration — increases the total complexity. And complexity is the enemy of reliability, security, and maintainability.

A 2020 study by Stripe (the payment processing company) surveyed over 1,000 developers and estimated that the average developer spends 42% of their time dealing with technical debt and maintenance, not building new features. Extrapolated across the global developer population, Stripe estimated the annual cost of technical debt at over $300 billion.

That is $300 billion per year spent not building new things, but wrestling with the accumulated complexity of old things.

WHY IT MATTERS

The software entropy problem matters because it is structural. It is not caused by bad programmers. It is caused by the nature of software itself: software is infinitely modifiable, which means it is infinitely additive. Unlike a building, which has physical constraints that limit modification, software can always have one more feature, one more integration, one more workaround. There is no law of physics that says "this codebase is full."

But there is a law of cognition that says: humans cannot hold arbitrary complexity in their heads. And when the complexity of a system exceeds the cognitive capacity of any individual, the system becomes a collective artifact — understood in pieces by different people, understood in whole by no one.

This is the state of every large software system in the world. Linux. Windows. iOS. Chrome. SAP. Oracle. AWS. The code works because statistical probability favors it: most of the time, the parts that are executing are the parts that are well-understood. But in the corners, in the dependencies, in the configurations that nobody has reviewed since 2018 — there are surprises waiting.

FUTURE — WHERE THIS GOES (SPECULATIVE)

AI coding assistants are about to make this worse and better, simultaneously.

Worse, because AI tools like Copilot and Claude Code generate code faster than any human team can review. The rate of code addition — and therefore complexity growth — is accelerating. If a team was adding 10,000 lines of code per month, an AI-assisted team might add 50,000. The entropy grows five times faster.

Better, because the same AI tools can analyze existing codebases, identify dead code, trace dependency graphs, and suggest refactoring opportunities. An AI that can read and understand 2 billion lines of code is more useful than one that can write 50,000 lines per month.

The question is whether organizations will use AI to build faster (adding complexity) or to understand better (reducing complexity). The incentive structure favors building. New features generate revenue. Refactoring generates peace of mind. In most companies, revenue wins.

And so the spaghetti continues to grow. Layer by layer. Engineer by engineer. Year by year. The most powerful systems in the world, held together by duct tape and prayers — and the quiet hope that whatever is in the corners stays asleep.

(Sources: NATO Software Engineering Conference Proceedings, 1968; Edsger Dijkstra, "On the Cruelty of Really Teaching Computer Science," 1988; Fred Brooks, "The Mythical Man-Month," 1975; Ward Cunningham, "The WyCash Portfolio Management System," OOPSLA 1992; Meir Lehman, "Laws of Software Evolution Revisited," 1996; Stripe, "The Developer Coefficient," 2020; Google Engineering Practices documentation; Reuters, "The World Runs on 60-Year-Old Code," 2017; COBOL Working Group, "COBOL in the 21st Century"; Stack Overflow Developer Survey, 2024; Standish Group CHAOS Report, 2023)