Yep. Also see twitter.com/jxxf/status/121900930843802…

Somebody asked this question as a reply to one of the tweets and the author replied: twitter.com/jxxf/status/121912818976887… > We considered a number of options, but decided that the fix was not making it about dates at all but rather offsets (e.g. "t+1 year", "t+2 years", etc.), which bypassed the Y2038 issue. > We then immediately called something else to do the final translation into dates for the CSV.

The only code you never have to touch again is code nobody is using. In which case, it's like a corporation declaring bankruptcy: the debt becomes moot. 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. twitter.com/jxxf/status/121900930843802… 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.