Back when I worked at LiveJournal, Brad Fitzpatrick commented:
Our standards are continually being raised, so by definition any old code is ugly because new best practices have emerged in the meantime.
This has always stuck with me in the back of my mind, but it came up again in a conversation earlier this week. In trying to find the right way to manage a backlog of technical debt -- a whole topic in itself -- I pointed out that the discussion conflated two issues: one was technical debt, and I called the other "technical depreciation".
Your code may have been great when you wrote it two years ago. It epitomized every best practice of the time and is completely bug free. Unfortunately, two years later, and without doing anything to it at all, that's no longer the case. It might not compile against a newer version of libc, some security vulnerabilities have been discovered, a required dependency is no longer in the repository, its logic may not have kept up with changes to the business, and so on.
(Some of my favorites: a blog engine that worked when you had 1,000 entries posted to a blog, but four years later, it slows to a crawl when it's got 1,000,000 entries. Or, scrambling to find a bunch of old machines laying around because you require an ancient OS that doesn't have driver support for newer server components. Or, being stuck writing for an obsolete version of perl's Catalyst framework because you're so far behind that it's near-impossible to catch up.)
In the case of technical debt, you (usually) decided to take shortcuts, so you hopefully know where they are. But spending time managing your software's depreciation is equally important, but far more nebulous. I think this is the baseline cost of running any piece of software: managing dependency upgrades, managing security upgrades, maintaining build and release scripts, updating documentation, revising configuration for a changing environment, and so on.
People often think that Newton's Third Law ("an object in motion stays in motion") applies to software. But the world is in a constant state of change, and assumptions -- from hardware choice to business logic -- will eventually no longer hold. And just like technical debt, the longer you put off addressing depreciation, the more disproportionate the effort will be to address it.