#080 - Technical Debt | The Inescapable Gravity of Our Decisions
Exploring the concept of technical debt from a first-principles engineering perspective.
Every engineer who has walked a construction site or reviewed a set of as-built drawings has felt it. It’s the moment you encounter a detail that makes no sense, a conduit routed through a column, a connection that is impossible to inspect or an elevation that simply doesn’t work.
It’s easy to look at this and mumble, "What were they thinking?"
In hindsight, we are all masters of our craft.
This is a common situation that touches every project and company. It has a formal name in the software development world: technical debt. But the concept is far too important to be confined to a single industry. It is a fundamental principle of any design and development endeavor, as relevant to a concrete floor slab as it is to a web application.
Understanding technical debt from first principles is not an academic exercise. It is a mental model for making better decisions under pressure, for understanding the long-term consequences of short-term trade-offs, and for recognizing that every design choice carries a hidden mortgage.
Deconstructing the Metaphor
The term "technical debt" was coined in the 1990s by software developer Ward Cunningham. He needed to explain to non-technical managers why his team needed time to go back and clean up existing code. He brilliantly framed it using the language of finance.
Imagine you need to ship a feature or design update quickly. You can take a shortcut, a "quick and dirty" solution, to meet the deadline. This is like taking out a financial loan. You've acquired a benefit now (completing the work on time) at the cost of future interest payments. That interest comes in the form of increased effort for all future work that has to interact with that shortcut. Adding new features becomes harder. Fixing an issue takes longer. The "interest payments" are the extra time and complexity you now face.
You can see the direct similarities to the construction industry.
Cunningham’s original idea, however, was more nuanced than just "sloppy work." He described intentional debt, a strategic choice to defer perfect design in order to learn more about the problem. It’s like building a temporary support system to erect a complex structure. The shoring structure is a form of debt; it's a temporary component that costs time and money to install and remove, but it enables the final outcome. The danger isn't in using the support, but in forgetting to remove it or trying to build the final cladding around it and treat it like a permanent component.
Over time, this precise definition has eroded. The term "technical debt" has undergone what's called semantic diffusion, it now colloquially refers to any mess, regardless of intent.
But framing it simply as a mess is unproductive. A more robust metaphor for engineers comes from a surprising place: aircraft maintenance. After a certain number of takeoffs and landings, specific parts of an aircraft undergo mandatory checks and refurbishment. It’s not a moral failing; it’s a planned, disciplined process of managing entropy. A high-quality engineering organization treats its designs the same way. After a certain number of change orders or design revisions in one area, that part of the system is flagged for a "refurbishment" to ensure its long-term health.
This leads to a more pragmatic definition:
Technical debt is the redesign effort required to make a future modification efficient.
Consider a foundation pour where the initial design included conduits for a future, unconfirmed expansion. Late in the project, that expansion is cancelled to save costs, but the conduits are already tied into the rebar. Removing them would delay the pour, so the decision is made to abandon them in place. That is the technical debt.
For years, this decision costs nothing. The cost becomes real the moment somebody needs to drill into that foundation. Without accurate as-built drawings, every drill location is a gamble against hitting a hidden, abandoned steel conduit. The 'interest payment' is the new risk, analysis, and workaround effort required because of that initial, pragmatic shortcut.
System Problems
If we accept that technical debt is an inherent property of building complex systems under constraints, the next logical question is how to manage it.
So how do we think about it?
1. Making Debt Visible
Technical debt is dangerous because it's often invisible to everyone except the engineers working deep in the trenches. One of the most effective management techniques is to make it visible. Imagine a system diagram of a water treatment plant, a P&ID. Now, imagine color-coding each component based on its design health.
Green: Well-documented, follows standards, easy to modify.
Yellow: Minor deviations, some complexity but manageable.
Red: Complex, poorly understood, deviates significantly from standards. Known as a source of problems.
When the project manager wants to add a new component to the system, you can immediately show them: "That's a great idea, but notice it has to connect through these two 'red' systems. That's why the level of effort is higher than you'd expect. We'll need to pay off some debt there as part of this work." This transforms the conversation from a subjective complaint into an objective risk assessment.
2. The Decay of "Active Knowledge"
The true asset of any engineering organization is not its software or its designs; it's the shared, active knowledge of how those systems work. This knowledge has a half-life. An engineer who spends a month deep in the calculations for a design possesses an immense amount of tacit knowledge. Six months later, after working on three other projects, that knowledge has dissipated. If someone else has to make a change, they must re-learn the system from scratch, a process that is slow and prone to error.
This is changing as orgs begin to think about the preservation and organization of data but that’s a topic for another day.
Managing technical debt is therefore an act of managing knowledge decay. This can be done by periodically assigning tasks that require engineers to work in unfamiliar parts of the system, just to refresh the team’s collective understanding and ensure knowledge doesn't become siloed in one person's head.
This is considered impractical at most firms and of course it depends on the context but it is worth considering. Does it make sense on any of your projects. In my opinion, context is king. Engineers provide better solutions when they have greater context. Your mileage on this may vary.
3. The Paradox of Better Tools: The Peltzman Effect
It’s tempting to believe that better technology, AI, advanced simulation software, automation, will solve the problem of technical debt. The reality is more complex, and is explained by a concept from safety engineering called the ‘Peltzman Effect’.
The effect states that when safety measures are implemented, people's perception of risk decreases, and they tend to behave more recklessly. When anti-lock brakes were introduced in cars, the hope was for a dramatic drop in accidents. Instead, the number of crashes remained relatively stable because people, feeling safer, drove faster and braked later.
In engineering, our advanced tools are our safety features. Because AI can help us analyze a more complex design, or because a powerful finite element package can solve an intricate model, we are emboldened to create even more complex systems. The tools don't eliminate debt; they enable us to take out bigger loans. AI can accelerate the creation of technical debt much faster than we've ever seen before. I have seen this again and again in my own workflows and in those I supervise.
The Takeaway
Technical debt is not a problem to be solved, but a reality to be managed. It is a fundamental trade-off, a force of nature within the landscape of engineering. Like friction or gravity, you can’t eliminate it, but you can understand and design for it.
Reframe Debt as a Strategic Tool. Instead of viewing all debt as a mistake, distinguish between intentional and unintentional debt. Sometimes, taking on debt consciously to meet a critical deadline or to learn more about a problem is the right engineering decision. The key is to make it explicit and have a plan to "pay it off."
Fight Knowledge Decay. The best defense against the compounding interest of technical debt is a culture of shared understanding. Make design health visible. Rotate engineers through different parts of a project or at least provide rich context to those that could benefit. Treat the clarity of your design and documentation as a primary deliverable.
Recognize the Human Element. Ultimately, technical debt is a human phenomenon. It’s a side effect of teams of people working on complex problems under pressure. The most robust systems are built not by teams who believe they can eliminate debt entirely, but by those who have the discipline and humility to manage it continuously.
I find this concept fascinating and I think about it often. If you want to dig more deeply into technical debt, Asana provide a great summary of it here.
If you have thoughts, share them below.
See you in the next one.
James 🌊