Technical debt is not debt; it’s not even technical

> Arguing over dictionary definitions is not going to lead to anything useful in this matter.

> If we are going to be pedantic

The whole article was about going to be pedantic over dictionary definitions.

"Now, one major concern in academia is rigor. Academics like to get deep into a topic, examine the nuances, and bring clarity."

I suppose it's hard to argue against that words in "technical debt" were chosen poorly: it's not debt and it's not technical.

Maybe better definition is needed.

The need to maintain or replace / upgrade infrastructure places an obligation (liability) on the owner of the infrastructure to do so.

Perhaps technical liability would be more accurate, but I like the sound of technical debt.

There is always the temptation to say, 'We have made something. It works. Pure asset.' (E.g. concept of passive income.) But it is seldom true over the long term. The debt is almost always there, or will be as the rest of the world moves on and the existing asset needs to be developed or becomes obsolescent.

The trick for asset owners (asset defined as the right to future economic benefits) to profit from an asset is to spend some of the returns from the asset on paying others to maintain and refresh the asset. In this way, the asset owner enjoys the truly passive net benefit.

Infrastructure carries both the attributes of a static, tangible thing (a good) and a service.

I like that the coding world is so conscious of technical debt, and it makes sense: the sector is moving so fast, and the fixes can be applied with access to a skilled problem solver, a computer, access to software and time. The maintenance &/or switching costs are comparatively low in comparison to the benefits.

I think that providers of physical infrastructure could pay more attention. Maintenance contracts and dilapidation reserves do make (small) inroads into acknowledging the ultimate sclerosis that additional large infrastructure introduces to the built environment. But the time scales for its regeneration to a large extent alleviate developers from the obligation to apply a more overarching perspective of the debt it will place on future generations to improve on what has been laid down.

Rather than questioning the term, it should be rolled out more widely.

Writing code to the "best of your ability" is something I've seen create a lot of problems because after you get about 75% done you probably realize how to do it better, and that happens repeatedly. In extreme cases I've seen mid-project framework changes multiple times.

Writing code that isn't great but works in order to ship a product in a timely manner incurs technical debt because you may have to do more work in the future to fix it once it is in use. But ideally your project is generating real income on that technical debt so it's probably better to have something to works right now vs something that's going to be perfect when it's done, eventually.

Bankruptcy metaphor is applicable too: when enough debt accumulates, all the capable engineers start leaving the team, and newly hired once never stay for long. The project will either get scraped as unsuccessful, or rewritten/replaced with another one.

This is why it is important to refactor dangerous system deficiencies sooner. If tech debt takes 2 weeks to clean, one can always squeeze that into the plans. If tech debt takes 1 year to clean, it is nigh impossible to persuade the business give that much time.