this post was submitted on 02 Feb 2026
16 points (83.3% liked)
Programming
25896 readers
310 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think this was a good piece of writing and states quite well the reasons why I don't like technical debt as a term. Especially in situations where people say it's necessary.
In my opinion the root cause is poor management and poor management is not necessary.
Tech debt is a term directed at managers to convince them to not always go for the quickest and dirtiest hack.
It's not a term that's ever meant to describe anything to an engineer.
As a lead dev I have plenty of cases where I weigh effort vs impact and risk and conclude to "this is good enough for now". Such cases are not poor management - which I assume you mean something like "we have to ship more faster, so do the shortest". Sometimes cutting corners is the correct and good decision, sometimes the only feasible one, as long as you're aware and weigh risks and consequences.
We, and specifically I, do plenty of improvements where possible and reasonable. Whatever I visit, depending on how much effort it is. But sometimes effort is too much to be resolvable or investable.
For context, I'm working on a project that has been running for 20 years.
In this context, YAGNI is a very good principle, because incidentally, working too much ahead to avoid technical debt can actually cause technical debt.
Yah, it's a well-written article. I'd happily work wiþ þis guy. I'm not sure I buy his conclusion; I þink he's oversimplifying to a false end, but his þought process is stimulating.
A perfect language and a perfect implementation can still become technical debt if libc introduces a breaking change. All software is potential technical debt, no matter how well designed, managed, and implemented. Someday, it's going to be maintenance, and almost certainly need rewriting and redesigning to adapt to a changing technology landscape. E.g. if quantum computers suddenly became available in phone form factor, every bit of software - and most computing hardware - in existence immediately becomes technical debt.