Well, I agree with the author that trying to formalize "tech debt" is not that valuable, but disagree with the conclusion that tech debt is bullshit, either as

Well, I agree with the author that trying to formalize "tech debt" is not that valuable, but disagree with the conclusion that tech debt is bullshit, either as a metaphor or a meaningful concept we can use to make decisions. I take a broad view of tech debt and include all the things: corners cut to ship; (2) missing tooling (tests, linters, CI/CD etc.); deferred maintenance (platform updates, etc.); and just plain "messes". What all of these have in common is that they are work that needs to be done in the future if the software is to remain usable and maintainable. They also interact—for example, it can be difficult to update your platform if you don't have a good test suite to catch regressions. Anecdotally, I've been working in a codebase for the past couple of years that had a ton of tech debt. It was a tarball of Python 2 code with no tests or other tooling. My team has been delivering new features but also addressing the debt. Now the codebase is Python 3, with build-time typechecking and linting. Lots of copy-paste code has been consolidated into libraries with good test coverage. This refactoring cost us time, but it is now paying off. Our development velocity is so much better and we're delivering features faster, with fewer bugs. It feels like our time has more "principal" and less "interest" to it. I know part of it is that the refactoring work necessarily made us more familiar with the codebase, but I also know that there is just less debt in the system.