What is "Tech Depreciation?"
As soon as you drive that software off the lot, its value will start going down.
"Tech debt" is a well-known and useful metaphor, but I've found it doesn't describe the whole picture. Technical debt is a choice, a trade-off—sometimes made well—that can be paid down. It describes a situation where we (hopefully) knew we were doing something that was going to impose limits or costs, but we could dig out of it.
Technical depreciation is the term I've started using for other things that make up sustaining engineering work, the things that never go away.
Dependencies and Best Practices
One type of tech depreciation comes from dependencies. If you build a container image of an application on an OS, if you use an open source library or framework, those will all need to be updated. Sometimes quickly, in the case of security updates.
Those are also trade-offs, but they're different enough from "technical debt" that I think it's worth talking and thinking about them differently. This is an ongoing source of maintenance, not a hole to dig out of once. Once you build a bridge, you have to keep repainting it. Once you ship a piece of software, you have to (or, at least, really should) keep its dependencies up to date. Otherwise, you do rapidly fall into a hole that requires significant effort to get out of, and that just keeps getting deeper.
Another variation of this can come from a team's understanding of their best current practices. Best practices on a team tend to drift slowly but inexorably, as new developers join and existing developers learn new techniques or find new tools. The further away those practices get from how a "stable" service was built, the more cognitive overhead and time will be required to change it again.
Foundational Assumptions
Another type might be something more akin to buying a minivan and then having SUVs become popular. Every team I've ever been on has made a decision that was not technical debt at the time. It was a reasonable-to-good design choice given what we knew about the world then. And two or three years later, some underlying business decision changed, and suddenly the value of that technical choice went down dramatically.
One team, for example, created tooling for building and scaling CSS for a content site that was a perfectly good way to do it—until the business wanted to dramatically rebrand certain parts of the site several years later. The dev and build tooling had been optimized for one global set of styles, and adding more complete sets required a certain amount of investment. In fact, if I remember correctly, we took on some tech debt (by bloating global styles and taking a performance hit) to make those investments, which we paid down later.
Planning for Depreciation vs Debt
The biggest practical difference I've between tech debt and depreciation is how you plan for it. Technical depreciation is, if you squint a little, constant. It's the wear and tear of running applications in production.
The updates for any particular dependency may or may not be predictable—the bigger the tool (frameworks, languages, kernels) typically the steadier the cadence—but "out of date dependencies" is an approximately weekly occurrence in any non-trivial application. This falls squarely into Marty Cagan's version of 20% time, or "sustaining engineering," a term I learned from Camille Fournier.
Refactoring to keep patterns and practices current also falls pretty neatly into this category. It's the type of work engineering teams should keep doing in small but constant chunks.
A change of fundamental assumptions may come as more of a surprise—and you could argue that when it does, this is functionally equivalent to Fowler's "inadvertant" debt. Personally, I find it's helpful to frame these moments as part of the scope of work to make the adjustments at all, rather than as a debt trade-off. Some of them may be fixed through regular sustaining eng work, but for the most part, these are substantial, risky changes that it does not make sense to undertake without a reason.
Technical debt, on the other hand, if it's intentional and in a healthy product org, is usually managed as a product planning trade-off. A team that says "we can get this to market and then we'll take the next sprint to clean it up" with no major feature work.