I think of tech debt as just another kind of debt. You borrow by doing something that causes your code to have features now that it would normally not have for some time if you “did it right”. From then on, whenever you try to move this part of your code forward, you have to pay interest. If you remove the debt, you are paying off principal and future interest payments are lower. There are penalties if you pay off debt for no reason (increased QA and destabilization).

Given that definition, any third-party dependency is technical debt. Third-party? Here’s how I am defining it for the purposes of this article. You are the first party, the platform you are writing on (e.g. iOS, Android, React, NodeJS) is the second party. Everyone else is third party.

Here are some of the ways in which third-party dependencies have debt costs:

1. You need to constantly update them. Even if you don’t want any of their new features, there might be security patches.
2. They introduce breaking changes. Since you are constantly forced to update, you might also get breaking changes, which includes new bugs.
3. They become unsupported. With enough time, this seems to happen to even the most popular projects.
4. The second-party (your platform) adds their own incompatible implementation. Apple did this to me by introducing better support for HTTP (with many compelling features) which totally replaced AlamoFire.
5. They don’t update on the same schedule as the second-party. This is not just the major releases, you also run into problems if they don’t keep up with the beta release schedule (you can’t move forward with your own adoption plans).

I have had all of these problems with dependencies I have taken on. Sometimes, it’s worth the trouble, but knowing all of the costs that might come has made me very skeptical of borderline dependencies.

Rewrite of Tech Debt Happens to You and Dependency Based Tech Debt based on Old, Flawed Work is the Jumping Off Point