technical debt vs technical depreciation

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.

Comments

[Pau Amma]

Isn't "technical depreciation" a variant of bitrot?

[Martin Atkins]

While I agree that it's important to pay attention to this problem of maintenance of existing systems, I'd argue that this is still a form of technical debt; not spending time keeping systems up-to-date is still a shortcut that leads to pain in the long term, which is exactly the definition of technical debt.

I think a better analogy is the distinction between taking vitamins and taking painkillers: the latter makes you feel better when you're sick, but the former can reduce the likelihood of getting sick in the first place.