The cost of third party dependencies

I've spent most of my career helping companies build web applications. Through my experience I have seen that not having a strategy on how/when/why to use 3rd party dependencies could lead to very high costs.

It all comes down on thinking about the sustainability of the project. A short-lived project will certainly not care much about upgrading dependencies.

When you don't know how long a project will last, you should not add third party dependencies without having a strategy.

The hidden costs

Having worked with several startups in the past, you start to see some clear examples of the hidden costs of 3rd party dependencies.

Here are a few examples:

Around 2018, I was consulting for a company that had a very large Angular 1.x application. They were having a lot of trouble hiring talent because nobody was willing to work with the codebase.

A giant monolith, very tight coupled with angular 1.x framework. They ended up rewriting the entire application in react, they paid the price for it. Features were added but at a very slow rate. Some competitors took the opportunity to fill the gaps.

Nobody wants to work with the codebase, so we need to rewrite

Another time, I was part of a team that inherited a react application that used several third party libraries, used for very small functionality but all over the place. When we decided to upgrade to the next major version of react, the work needed was not a small task. Several dependencies were unmaintained, some had to be swapped out, some we needed to implement by ourselves, some touched large amounts of files.

We can't upgrade because our libraries are not compatible with newer versions

Think about the future

A good strategy, is whenever you want to add a dependency, think about future implications. What is the impact and risk of a given dependency, when you discuss this with your team, you can minimize some costs.

To do this, ask questions like:

What will happen if the package disappears? How much effort will it take to fill the gap?
How can you build measures that allow an easier change of implementation with a different dependency if needed?
How long has this package been around? How long will it last?
How much to make as a priority to stay up to date with the latest changes?
How can I react to critical bug fixes and vulnerabilities?
How can this impact the performance of the application? Will the bundle be too big? will this work on limited hardware?

If something is a small utility, think of writing it yourself and avoid using a dependency. If its big or you don't have the expertise to build it, use a dependency but think from the start how to make it easier to transition to different implementations.

It is also important to code loosely coupled from frameworks, this might help on upgrading frameworks or when a package is overhauled and the API is very different. You can at least know your business logic can be used and does not need a rewrite.

Every dependency you add is one more point of single failure. - Jeremy Keith