[BeetleB]

>considering timelines in engineering are to support a version for 60 years.

In the vast minority of cases.

Not in most electrical engineering (except power plants), nor in computer engineering. 60 years ago was 1959. What software/computer project from that time is still running?

Even moving outside of the electrical domain, how many physical products outside of civil engineering is expected to last that long. I certainly can't expect support for my car for longer than 25 years.

[WorldMaker]

If there's a difference it's not time scale necessarily, it's that CPAs are better at amortizing support/maintenance costs across decades. CPAs have amazingly detailed depreciation charts for non-software engineering lifecycles. If you build a civil engineering project, you figure out asset depreciation versus maintenance schedules, and you budget accordingly.

I've yet to see a CPA adequately depreciate software assets, anywhere. Maybe we should help them out by building better depreciation schedules. There seems to be a lot of CPAs that don't believe software depreciates over time, and maybe that's the largest disconnect in labeling it "tech debt", because accountants hear that term and think they can ignore it on a balance sheet they don't care about, but "tech depreciation" might actually scare them straight (until they find the tax advantages in calling it that).

[BeetleB]

They really need our help :-)

In a previous job that was mostly in an engineering/manufacturing department, but with a lot of Perl/Python automation scripts, we had an internal conference. One of the keynote talks was when not to automate using SW. It went into the cost of maintaining SW over the long term - including the fact that authors leave, and people who understand their scripts require higher salaries. Most people who write these scripts are not hired for SW roles, so their replacements likely cannot debug/extend.

[djsumdog]

Classic cars can still get parts after 25 years, but a lot of times its custom machine shop stuff. There is a market for it. Really there's also a market for restoring old computers (look at The 8-Bit Guy, LGR, The Living Computer Museum (Seattle) and all those other people who restore old hardware for fun and education.

But I get your point, those are special cases for preservation. For mainline things, especially with today's processes for continual integration, dependency checking and advance build tooling, dependency rot is something that should be accounted for in all software project plannings. If your dependencies are a few months out of date and you don't have the time to update them and re-run tests (people write tests right?) things are just going to hurt more and more later.