Technical Debt Is a Myth

Technical entropy.

Entropy is unavoidable is the outcome of any work occurring.

> It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore.

The risk of this happening is more or less measurable and is the debt. Denying responsibility doesn’t make the debt not exist. It might mean you’re so far removed from understanding how your (sub)systems function that you’re unable to assess it. It may be so complex that no one is able to quantify it, in which case I suppose “it doesn’t exist” might be accurate enough — either your business fails or it doesn’t based on the success of your subsystems, and your business outcome is the measurement. I’d rather have someone else be the measurement.

A lot of your framing has to do with what's expected of the system. Like, scaling from 100 users to 100M is an expectation not a property of the software. Making that library _more_ secure is also an expectation. Expectation becomes debt when your current expectation exceeds the limits of the system. When that happens it's largely because someone, often not a developer, changed the expectations. When that happens the difference between the expectations and actual system has to reconcile somehow and that's usually via some "shortcut" and there's some associated cost.

So, within your framing, the point is just that when things change (due to no fault of your own) the whole organization has to adjust expectations or you have an organizational issue.

> Well, now all your Cobold developers have retired and you need to add new features to that tool. It's tech debt.

A new feature isn't tech debt... it's a new feature. I don't know for other people but at my workplace they're two very different types of TFS items.

[Up to the expected quality of a Medium post.]

It renames Tech Debt as an "organisational mortgage—a loan the business takes out against future capabilities to deliver, which has to be paid back with interest. In this way, it’s no different than any other loan, or any other debt the organisation incurs."

The difference of course is that this debt has a technical solution, as opposed to a financial one.

The article doesn't say a lot, I agree with you there. But I like this part

"should be a deliberate choices. It has costs, interest, pros, and cons."

Any "Technical debt" that is not a deliberate choice fails to fit the analogy. Often it's just crappy design or implementation. There are times that you need to take on some debt to move forward because you don't have the resources to do it otherwise. That to me is where the analogy works well and the important part is to make sure management is making that call not some overworked developer.

It seems like they are trying to do otherwise but I see this article as perpetuating the basic problem with "technical debt" which is the analogy with debt. But what do you expect from an article on Medium?

If you take on debt the bank is going to question if you can pay it. You're going to have to go through a formal process and bring in expensive experts such as accountants to justify that taking on debt is worthwhile.

Most "technical debt" is blundered into out of ignorance. Nobody sits down and thinks "we can save two hours now at the cost of three hours later" because it would probably take four hours to do the calculation. Sometimes it really is like that but frequently it is like "we can save two hours now at the cost of of two months later", such as when people make an incorrect database design that involves cleaning up corrupt data later on. Cases like that dominate the cost of "technical debt" to the point where the 2 hours now, 3 hours later cases just don't matter.