[ineedasername]

There's always tech debt. It starts to day you build something and ends when it stops being used. How many thousands of python 2.7 programs had "no" tech debt when developed bit now have tons. Tech debt isn't binary, it's a sliding scale.

[stallmanite]

Seems like a classic-style omnipotent god could write anything conceivable in some eternal Lisp dialect that he maintains personally. If he’s really capable of violating thermodynamics he should be able use knowledge of the future to ultra-waterfall the design and implement it flawlessly thereby completely avoiding accumulation of technical debt.

It’s fun to imagine Jesus returning in 30xx AD but this time instead of absolving the world of its accumulated sin he wipes away the accumulated technical debt of 1.5 millennia worth of corporate IT

[abiogenesis]

If you were "all knowing", you would've known that Python 3000 would not be backwards compatible and waited until it is released (assuming that you don't have a deadline, such as 7 days).

[zaarn]

Even if you had a deadline, you'd know all tech debt and could anticipate it beforehand.

[falcolas]

The joke is (and it is a joke, mind you) that an omnipotent and omniscient entity could have written a perfect program in, say, 2005, and it would have no tech debt now, because it's never needed to change since it was written to anticipate every need for the program in the first place.

Hell, since the writer was omnipotent and omniscient, the code was even built with the ability to perfectly modify itself when the company changed the DB on September 12, 2011 at 3:24 in the morning.

[ForHackernews]

You mean all the Python programs started before 2008, right? Because that's when it was announced that they were sunsetting Py2.

So any projects started since 2008 that were written without Py3 compatibility had known tech debt they were choosing to take on.

[ineedasername]

Yes. Why does it matter than the particular example I chose had a cutoff date 2008? It's the same issue with any language, program, platform, OS, etc. Even if you implement the latest stable version of any of these things for any project, tech debt begins immediately. In fact if you're dealing with established enterprise software, you know right away what the roadmap & minimum end-of-life is from the day it's released. (as side topic, that's part of why mediocre enterprise software is often chosen over newer better options: because predictability is valued over the newest/best/fastest that may be subject to disruption if the vendor goes away or gets acquired-- something I've seen happen a few times. A vendor gets acquired, we get a "Hey Great News!" message from them along with an "Oh by the way our new parent company is transitioning everyone off our platform to their own completely different offering over the next 6 months, hope you have the capacity/bandwidth to deal it #sorry-not-sorry"

[ForHackernews]

> over the next 6 months

My point is this is a very different situation from the Python 2->3 transition.

If you have 12 years' notice to make some changes, I don't consider that technical debt: that's the normal price of maintaining software in a changing world. It's not "debt" that costs "extra interest" to pay back for questionable choices made previously.