Hot take incoming. Buckle up.
I've spent quite some time writing about technical debt, preaching clean code practices, and advocating for sound...
For further actions, you may consider blocking this person and/or reporting abuse
Why do you think manager didn’t push his team under pressure deliberately? Or more likely because there wasn't any other viable option at the moment except inventing a time machine and travel back in time to prevent that bad decision that caused such situation.
I like your hoisting of the problem from engineering to management level, but I don't see a reason not to keep calling it a "technical debt". Everyone understands the term and the substance remains the same - the code is technically bad and it is causing technical problems because someone decided not to solve them in advance in exchange for some quick wins. You're just blaming other kind of people for creating it.
You're right that managers often don't have better options because they're usually caught in their own cascade of impossible constraints. The VP needs numbers for the board, the board needs metrics for investors, and nobody in that chain is getting the time or resources they actually need either.
But here's why I still think the term matters:
"Technical debt" frames the problem as a moral failing that needs to be "paid back." It carries all this baggage about borrowed money and responsibility and whose fault it is. When you say "we have technical debt," leadership hears "the engineers screwed up" even if that's not what you mean.
Compare that to saying: "We optimized for speed in Q2 to hit our fundraising milestone. That bought us 18 months of runway. Now we need to allocate 3 engineer-months to address the maintenance costs of those decisions."
Same situation. Totally different framing. One sounds like accountability and planning. The other sounds like blame and cleanup.
The substance isn't quite the same because the metaphor shapes how we think about solutions. "Debt" implies you should pay it back ASAP and feel bad about having it. "Maintenance cost" implies you should budget for it as a normal part of doing business.
You're right that I'm just shifting blame up the chain, but my real point is we should stop playing the blame game entirely. The system creates these pressures. What we need is honesty about trade-offs and realistic budgeting for consequences, not finger pointing about who "borrowed" what.
Though I'll admit: if everyone's going to keep saying "technical debt" anyway (and they will), then yeah, at minimum we should all be honest about what created it instead of pretending it materialized out of thin air.
If they hear "engineers screwed up" when you say "tech debt" that's on the person presenting it. Not the leadership and not term.
The idea that it is "money that needs to be paid back" is correct! At some point, someone (a dev or other) decided to borrow against the future for the sake of simplicity (or familiarity) right now. And when you start having problems, that is the debt coming due.
I understood the article as a bit of an exaggerated story against using "tech debt" as an umbrella term. It does fit a bunch of scenarios, but it's more meaningful if we start using more specific expressions for other cases which were not simply to "borrow time".
I came here to say something like this! Thank you!
Tech debt is a useful term that this writer has had weaponized against them too often.
Great post!
I've always considered myself an engineer, not an artist, even though a lot of our work is creative. As an engineer, my job is to get people over that river by building the best bridge possible. That doesn't mean it's the most beautiful bridge. It doesn't mean it's the most elegant bridge. It doesn't even mean it's the most efficient bridge. It just means it's the one I could build that was most appropriate at the time.
I think the cost of learning should also include only having theoretic knowledge. To ride a bike you know you have to hold the handlebar to steer and push on the pedals to get speed. But the first time doing it is awkward.
This is a great addition. The gap between knowing a pattern and executing it well is real - and invisible to people who’ve already crossed it.
You can understand dependency injection in theory and still completely fumble it in practice: over-inject everything, create circular dependencies, end up with a constructor that takes 47 parameters. That’s not technical debt, that’s what learning actually looks like.
This awkward phase is unavoidable. You don’t get smooth without being clumsy first. Imperfect code written while learning is a normal cost of growing engineers, not a failure.
The problem is when orgs treat this learning cost as corner-cutting, or assume hiring seniors makes it disappear. Even senior engineers are juniors when they’re learning a new domain, framework, or pattern.
It is NOT invisible to actual competent people who have crossed the line. Some of them/us remember the effort and recognize what it takes. Honestly that might come from teaching.... but it is not and should not be okay for it to be invisible once you cross it.
We loved your post so we shared it on social.
Keep up the great work!
Thank you!
This isn't a great post because of really any groundbreaking conceptual realizations, but holy hell did you hit it on the head with respect to framing.
For us as developers, architects, engineers and co., perhaps we could do a better job of quantifying future costs, but to what end? If the main objective is secure series x of funding, that feedback becomes not only not a now issue, but words they won't even hear (and we probably wouldn't be correct).
Loved your post. To whatever holidays you celebrate or none at all, I hope they're great (or I guess I could have an uncaught null there).
Kindly,
Chris
Haha, with this current velocity of the evolvement of software development, I try NOT to invent anything new ( or groundbreaking if i could ) but I believe there's so much more to the existing concepts that I believe we should look more into it and maybe re-evaluate it to adapt to evolving contexts.
And thank you! In Cambodia here, Christmas isn't really a cultural or a big thing, but it's growing, especially here in the capital city in Phnom Penh where I live - I'm pretty much one of the only few here with a full, overwhelming Christmas spirit every year but I'm happy to be all over in my head all by myself haha.
"evolvement" the word you want is evolution.
While I agree with much of this, it is a gross oversimplification, and doesn't do justice to what happens in the real world. And now with AI, while it might be able to minimally help with fixing existing debt, the amount it is going to generate will be overwhelming and there won't be any real devs left who know how to actually do the job. Its gonna be a crazy time.
We call the tasks that don't contribute directly to product features as "Enabler" tasks rather than having everything labeled as "Stories".
So rather than calling it technical debt we call it Enablers
I like that framing. Calling them Enablers makes the intent explicit: this work exists to make future work faster, safer, or even possible at all.
What I’ve found is that once you name these tasks as enablers instead of “debt,” the conversation shifts from “why are we cleaning up?” to “what does this unlock?” It stops being about fixing past mistakes and starts being about increasing delivery capacity.
Same work, different language.
That’s exactly how it looks! Especially when it comes to slightly older code. On the frontend, I sometimes feel like the code is already legacy the moment a project starts 😄 A new library or store pops up right away, the version gets bumped, and boom - we already have “technical debt” 😄
haha frontend development is the perfect example of why "technical debt" is broken.
You're not in debt because React 19 came out three months after you chose React 18. You made the best choice available at the time. The ecosystem just moves absurdly fast.
Calling that "debt" implies you should have predicted the future or made a mistake. But what were you supposed to do but wait indefinitely for the "final" version of JavaScript tooling? (Spoiler: there isn't one.)
pure entropy. The code didn't get worse, the world around it just moved faster. Budget for it as a maintenance cost, not a moral failing.
"debt" in NO WAY suggests one made a mistake.
Most adults are in debt due to paying for medical costs or education.
What you are actually suggesting (reasonably, I think) is that we need MORE WORDS than tech debt. We need something to cover "keeping up" and "erosion of the platform", etc...
I only came across the term 'technical debt' a few years ago and even then felt it was an oxymoron. I can't think of two words that have less in common than technical and debt. The term is meaningless and should be dropped from the software developers lexicon.
I felt this post, sometimes I frame these known shortcuts as fast follows. So I take them and deliver the bulk of the feature, while saying "this will break soon, we have to have time to work on making the feature solid". So far it has been working to some degree
Great post!
Thank you!
The term technical debt is what is used in the industry. Even if it isn't the best metaphor.
If it were not already the ubiquitous term, I would have preferred to call it code pollution. I think pollution is a better metaphor than debt.
What annoys me the most with technical debt is that managers roll other unrelated things into the same bucket.
User-facing defects (bugs).
Necessary maintenance, which can be neglected and become deferred necessary maintenance
Those things are also very important. But they are not technical debt. They are not code pollution.
I agree that the key issues are usually management and lack of focus/investment on NFRs (Non Functional Requirements)
what is interesting is that Wardley Maps and the EVTP (Explorers, Villagers and Town Planners) are a much better way to explain what is really going on, since as the article correctly says, Technical Debt is a really bad analogy
I agree with your points on how the term "Technical Debt" isn't suitable anymore, but I also think that the term itself isn't the problem; as you explained, a good manager will try to understand the term no matter how it's worded, a bad manager will weaponise it as much as they can. "Maintenance Cost" could then be turned into "Why did you let maintenance cost accumulate? Shouldn't you make sure your code is maintainable?" by a bad manager. So I'm afraid you can change the term, but you can't change the people