- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
To be clear: I do not think we should actually forget technical debt. Also, this is not the nth post discussing if “debt” is an appropriate metaphor. I do not have a strong opinion regarding the metaphor. My point is rather that I realized in a recent discussion that in the end, it is not so much about technical debt but rather about something else, and I wanted to share the thought.
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.