[antiquark]

> Computer Science: Existential risks posed by technical debt

The term "technical debt" has always rubbed me the wrong way.

Most technical decisions were sound... at the time!

I agree, people from 1999 didn't predict what would be happening in 2019. But why is that considered to be some sort of debt?

[sddfd]

That is not the only way technical debt gets introduced.

Often, teams cut corners to release a feature earlier/on time, and only make it work for the MVP use case without restructuring the codebase to fully accommodate the change. In this setting the term debt is pretty fitting.

[lumost]

true tech debt occurs when a business under-invests in their core technology over a long period of time, or deal with concept drift in its business. I know of multiple fortune 500's that are reliant on bespoke emulation of hardware and operating systems that haven't existed in decades, even worse the source code for the software they're running may no longer exist in any usable form.

In many modern web companies a given project has a useful life of ~3-5 years, if its still running by year 8 with a team that's been on KTLO a few things are probably true.

A: No one knows how to productively add features.

B: The business need for the project was much larger than the KTLO funding would imply.

Odds are at this point there are a long list of user complaints, year+ old feature requests, and excuses being made to the board for why some initiative is facing yet another delay.

Perhaps we should be talking about software depreciation rather than tech debt?

[sddfd]

Let's also talk about why LTS is a dangerous idea: It provides an excuse not to update.

Many tech debt traps start with relying on an LTS version of OS or libraries. The philosophy behin that is, that software behaves like a chair: You buy it once, and then you sit can sit on it until it is no longer needed.

A much better analogy is a horse: You need to feed and take care of it daily, and you need to be ready for it do die when you still need it.

[sgt101]

Long term systems evolution and management might be a better way to think about it. Lehman at Imperial looked into it in the 90's (https://www.researchgate.net/publication/220902836_On_Eviden...) but no one has done much since, and yet we are increasingly dependent on platforms and 20+ year systems.

No one knows how to run and manage these systems, yet we do it all the time!

[dnautics]

Debt is not always bad.