Posted August 06, 2024 by JaumeGreen
#technical debt #programming #terminology
You may have heard about technical debt, or you might not. Just in case let's define it, and to start let's see examples of what is NOT technical debt.
From here we can extract some ideas of what is tech debt.
One can be right, and still end in the bad place. Be it that they do a throwaway that they bosses want to keep, or that they do a nice job and time passes and the program needs some extra maintenance just to keep up to date.
And how much would it cost to solve a problem? It depends.
It depends on so many things that making a list would not be useful. Just take my game into consideration. It took 6 different days to finish it, the minimum I worked it would be about 2 hours, and I don't think I worked over 4 hours. That leaves us in between 12 and 24 hours of coding.
Just moving the code to the right places, so it's not everything on the same file, and testing it, it would take, 4-8 hours, depending on if it works easily or I have to redo some things. An expert in Godot could probably do it in a couple of hours and also create a reasonable structure for the code and items in that same time.
You can see how costly is technical debt if you need to pay it back. This is why some projects decide on a rewrite instead of a refactor. It's expensive but they hope the next code will be more maintainable.
But nothing in here answers the question: Why is Technical Debt a harmful term?
Mostly because someone took an economy term to make a comparison without knowing all that it implies. What follows is a rough explanation, thread with care and look for real economists, not just ex-EvE online players.
We have several two main kinds of debt.
What most people understand with debt is the first one.
The last point would be equivalent to having a project which can't be updated and thus we lose customers.
But company accountants are more familiar with the second.
How can we make people with the latter mentality take into account that technical debt is like the former? That's why most companies don't pay back technical debt as they should. For them debt is good.
Probably we should have kept using architectural and housing market terms and explain that we made a shed, a temporal housing solution, the house is in need of repairs, or no longer up to code.
It's longer to explain than technical debt, but at least we wouldn't be playing on the C-suite home ground. Using the right terminology is important when explaining things, and the wrong concept can set us back for a long time.