Technical debt is entered into deliberately, as a trade-off for time that must be paid back, with interest. There's no technical debt that isn't "self-admitted".
Technical debt is entered into deliberately, as a trade-off for time that must be paid back, with interest.
The implication here is that if only you had enough time you wouldn't have any tech debt. I don't think that's true.
Some of the tech debt is due to not having enough knowledge about the future of your system; what it needs to do, how it'll be used, etc. You have to make a decision about the tech now and sometimes that decision turns out to be wrong, or at least incomplete, which leaves you with some debt that will need paid off some time.
I also believe some tech debt is unavoidable due to churn from outside of the system. Best practises for a given part of an app aren't fixed (eg React class components shifting to functional components), so sometimes something that was once good can turn into debt over time with no input from you.
The term "tech debt" means deliberate choices to compromise the system in a controlled way, to achieve a purpose. E.g. speed to market.
That's true, which is why things can become debt if you fail to maintain them, upgrade them, change them when the customer's requirements change etc. By choosing not to maintain code and do other things instead you're allowing parts of the system to decay. That is a source of tech debt (arguably the most common IMO).
Publicly self-admitted, in this case. Apart from that: if I inherit the code base of a bad programmer on my job, with a lot of technical debt, which part of it is a deliberate trade-off? It's still "time that must be paid back, with interest", but how it came to be is not part of the definition. The term is merely meant to help confer the problem to non-technical people, who _then_ can make a conscious decision to accrue technical debt. If they do so out of incompetence, it's still technical debt.
> but how it came to be is not part of the definition
It's possible the people working at the time were not conscious of the trade-offs they were making. But it still happened and that's how it came to be.
> if I inherit the code base of a bad programmer on my job
It sucks, but it's almost guaranteed to be the case, to some degree. Think from the company perspective. You're thinking too much from your personal perspective, which is kind of irrelevant to the company. You're not using the term just for you.
I do, rest assured, part of this is my job description. I'm just bumping over the assertion that a deliberate trade-off is a prerequisite for technical debt. It's too specific a reason, and like saying your expenses are higher than your earnings, that's why you are in debt. But in reality, there are many more ways to end up in debt, spending more than you earn is just one possible cause.
If you identify technical debt, either hypothetical or existing, the term is an option to explain this to your superiors in a way they might understand. They'll know that they need to do regular small investments to pay it off, or chose an alternative option to avoid it. But that's all there is to it.
Your bank goes bankrupt and you lose your funds. A good you purchased turns out to be stolen. You lose a lawsuit. You purchased a company in an equity deal and the company turned out to carry liabilities (just a note, I'm not from the US, so details might actually be different there).
Likewise, for technical debt: a dependency you relied upon is not maintained anymore. There is an exploit found, or regulation changes, and you realize you used the forbidden pattern everywhere.
Basically: earnings minus expenses are the operating result. Concious decisions to accrue technical dept would be the equivalent. But there are costs directly affecting equity as well, which can still result in debt.
I think the trade-off is at the company level. They hired a worse programmer to save money/time back then and accelerate development in the short term.
How would they be in a position to judge programmer competence? It might well be the person was hired based on being cheaper and/or a personal relationship (boss' nephew or manager's room-mate) but that is not necessarily an indication of how good they might be.
More often it's just a sign of a new company not knowing what they are doing and making unforced errors as a result, rather than a conscious debt/investment transaction.
Yes, that probably is more likely. I was merely trying to paint the decision makers in a good light to offer an alternative viewpoint. I usually default to the managerial incompetence view, wanted to have a change.
Agreed, just like real debit it isn't necessarily bad as long as you have a valid plan on how to repay it. And, like real debt, taking on technical debt may allow you to do things that wouldn't be possible otherwise (getting a product to market in time for example), similar to how if you refuse to borrow money to buy a house / car but save up for it instead you'll probably have to wait a long time before having it.
The problem though is that in the financial world there are rules and often laws about how much debt is acceptable and a bank will generally refuse to let you get into dangerous levels of debt whereas there are no such rules concerning technical debt so a company can keep piling it on until it eventually causes a collapse.
Not always. Technologies get old and have to be replaced over time. Tech debt is now mostly treated as a part of a product and developers do not decide what to do about it, but bussines through roles like product owners.
