> Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596.
There are plenty of counter-examples, but I like the example of video games.
https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-cod...
There's a pretty clear ship date, after which you never touch it again.
Even in the world of SAAS, there are plenty of services or libraries that you write that serve a single purpose, are good enough, and never get touched again.
Even the code you mention isn't a great example for your case. In theory it was throwaway, but now that it's out there, you can bet that plenty of people will be touching it. And you're also ignoring the path not taken. This beloved game didn't get a sequel, despite plenty of demand. If the code were in better shape, might it have had one?
Otherwise, you always have to deal with it eventually. Look at the Y2K problem. or how the 2038 problem is starting to crop up already, exposing significant levels of technical debt. https://twitter.com/jxxf/status/1219009308438024200
I also think technical debt does accrue interest over time, albeit not as linearly as a modern installment-plan debt does. That's because it slowly falls out of sync with people's memories. With libraries, with operating systems, with techniques. Bad code I wrote 10 minutes ago is pretty easy to clean up. But the next day, the next month, the next year? The cleanup gets more expensive. At some point the work becomes more archaeology than normal programming.
It's also true that actual foundations have something in common with foundational code. But that's a different aspect of programming than what tech debt is pointing at.