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.
Technical debt is not messy code. It is a lack of understanding. The code is the symptom. The disease is that the system was never reorganized to reflect what its builders learned along the way. Every feature added without reflection is a layer of sediment burying whatever understanding existed before.
Simple Picture
Imagine a library where new books are added by throwing them on the floor. After a few months, you can still find things — you remember where you tossed them. After a few years, only the original librarian can navigate the piles. After the librarian leaves, the library is functionally empty: the books are all there, but finding any specific one takes longer than writing it from scratch. The library has no debt to anyone. It has a deficit of organization, and the deficit compounds with every book added.
The Compounding Tax
The economics are simple: either you pay someone to refactor and 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.
That bewildered staring compounds. Complexity is more apparent to readers than writers — if you write code and it seems simple to you, but others think it is complex, then it is complex. The writer’s fluency is a local illusion; the reader’s confusion is the system’s truth. A general sense of confusion builds and builds. New hires spend weeks trying to understand systems that no one bothered to make understandable. The people who built them are gone. The intent behind decisions is buried in commit messages no one reads. The fog of work thickens until the codebase becomes Churchill’s report: defending itself against the risk of being read by its very length.
Organizationally, you pay in velocity and turnover. Talented people leave after a few rounds of this. You cannot expect productive work from someone navigating a culmination of rushed code, poorly understood requirements, and shortcuts made by people who no longer work there. At that point the technical debt balloon has popped and you are in possession of a toxic asset.
Oracle Database 12.2 is the canonical terminal case: 25 million lines of C code, held together by thousands of flags interacting 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. Rinse and repeat for another two weeks until you get the incantation right. Then add a hundred more tests to protect your fix from the next developer. A new feature takes six months to two years. The system survives not because of good design but because millions of tests act as an exoskeleton — the understanding is gone, but the test suite remembers what the code no longer knows. This is the firefighter trap at the code level: each fix adds complexity that makes the next fix harder, and the developer who finally quits will never return.
Organizational Amnesia
The same dynamic operates at the knowledge level. Most companies should never have wikis — successful wikis like Wikipedia are powered by an army of editors, and most organizations will never prioritize that much content strategy. Poorly managed knowledge leaves organizations with the memory of goldfish.
I can’t tell you how many new product initiative meetings I’ve been in where no one remembers the meeting about the exact same thing from two quarters ago. It’s like Groundhog Day, but you’re having the same meetings over and over.
This is the problem definition trap at the organizational level. The problem was identified, discussed, and forgotten. It resurfaces as if new. The same arguments are rehearsed. The same conclusions are reached. No one remembers the previous conclusion because the organization never reorganized its knowledge to reflect what it learned.
The Theory of Constraints adds the operational cost: every meeting about a previously solved problem is time stolen from the constraint. The sabotage manual’s instruction to “refer back to matters decided at the last meeting and reopen the question” is indistinguishable from an organization that simply forgot what it decided.
Dimwit / Midwit / Better Take
The dimwit take is “we’ll clean it up later — just ship it now.”
The midwit take is “we need dedicated refactoring sprints to pay down technical debt.”
The better take is that 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 flip side is premature aestheticization — trying to make things beautiful by abstracting away underlying details before you really understand the problem. Visible ugliness virtuously reveals the factor of ignorance; premature elegance buries it under a surface that looks clean but is not understood. The engineering algorithm encodes this: questioning and deleting must precede building. A codebase that grows only by addition, never by reflection, is not accumulating debt — it is hemorrhaging understanding. And understanding, once lost, is more expensive to recover than the code was to write.
Main Payoff
The deepest reframe: technical debt is not a financial metaphor about borrowing from the future. It is an epistemological metaphor about failing to learn from the present. The code works. The features ship. But the system contains no record of why anything is the way it is — and without that record, every future change requires rediscovering what the original builders knew and forgot to preserve. The will to think applied to organizations: the system that never pauses to understand what it has built will spend all its future energy on bewilderment, which is the most expensive form of ignorance.
References:
- Dave Rupert, Technical Debt as a Lack of Understanding