The code still runs. Nobody left in the building knows why.
Oracle Database 12.2 is about 25 million lines of C, held together by thousands of flags that interact in mysterious ways. Fixing a single bug means spending two weeks understanding 20 different flags, adding one more flag to handle the new scenario, then running millions of tests across 200 servers for 30 hours, and getting back 100 to 1,000 failures. Then repeat until the incantation is right, and add a hundred more tests to protect the fix from the next developer.
The usual name for this is technical debt, pictured as messy code: shortcuts taken to ship faster, to be paid back with a cleanup later. But what exactly was borrowed? The Oracle code works. What its developers lack is an understanding of why it is the way it is. Technical debt is not messy code. It is a lack of understanding.
Ward Cunningham, who coined the debt metaphor, described the mechanism:
If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.
Where the understanding goes
Each feature teaches its builders something about the problem. If the code is reorganized to reflect that lesson, the understanding lives in the structure, where the next reader can find it. If the feature is simply added, the lesson stays in the builder’s head, and the code gets one layer harder to read.
The builder rarely notices, because complexity is more apparent to readers than writers. If code seems simple to its writer but complex to everyone else, it is complex. Then the writers leave, and their intent survives only in commit messages nobody reads.
So the economics are simple: either you pay someone to reorganize after every major iteration, or you pay every developer who touches the project, until the end of time, to stare at the code for a few hours and wonder what the hell is going on. Organizationally you pay in velocity and turnover, because talented people leave after a few rounds of this. At that point the debt has become a toxic asset.
Oracle survives because millions of tests act as an exoskeleton. The test suite remembers what the code no longer knows, and each fix adds a flag that makes the next fix slower, the loop of the firefighter trap.
Why cleanup sprints miss
If technical debt were messy code, the remedy would be a dedicated refactoring sprint now and then. But technical debt is not a backlog item to be prioritized — it is the continuous absence of understanding, and the fix is not periodic cleanup but a culture that refuses to add without reorganizing.
The counterweight is premature aestheticization: abstracting away the underlying details to make the code beautiful before you understand the problem. Visible ugliness at least reveals the factor of ignorance. Premature elegance buries it under a surface that looks clean and is not understood. Reorganizing helps only when it follows understanding.
The debt metaphor suggests borrowing from the future. The Oracle case suggests something closer to failing to learn from the present: the features shipped, but the system kept no record of what building them taught. Its tests record everything that must not break, written by people who could no longer say why. How much of your own codebase is that kind of record?
References:
- Dave Rupert, Technical Debt as a Lack of Understanding