The Dangers of Dependencies

So what is so bad about software dependencies? Nothing per se, but there are some inherent dangers in relying too much on other software to make your product or service a reality. As a developer and product creator, I’ve learned the hard way that going too far down the rabbit hole can lead to more time upgrading and maintaining your dependency leverage than innovating your product.

So what about the dangers?

1. 1. Updates that are difficult to keep up with logistically
   2. The updates that never come or not resolved in a timely fashion
   3. Obsoletion
   4. When the free ride is over.

Breakneck Update Velocity

Updates and revisions can happen so quickly. You have a hard time keeping up. And with every update requires testing, review and re-deployment. More time. And as they say “Time is money, friend.”.

The Snail Pace of Unresolved Issues

Conversely, when updates are lagged, delayed or the module becomes unsupported any the developer going AWOL, it can lead to a slow and stead slump into brokenness. Issues go unresolved. Security issues cause other problems and contributions to the project or newer features are left on the table. We’ve seen this with Probo where we’ve had dependencies version themselves out of support with the upgrade of other technologies and we’ve had to find other solutions that are usually not a 1:1 fit.

The Issue Queue Can Be Tricky

Sometimes bugs and issues may have patches or remediations in the pipeline, but never seem to be deployed. This leads to manual patching or having to seek alternatives. Which means you get to maintain how and when the software is patched in your project. More overhead.

Beware of the Tow Truck

Software developers can pull their dependencies from repositories or make them premium. This means what you leveraged as open source, you will now have to pay a licensing fee to use. This happened just recently with Bitnami. All off their open source containers and helm charts were placed in legacy status in favor of a subscription model. This means the images are there, but no more updates which will ultimately lead to security issues.

I get that all projects are not on the same development schedule. But allowing your dependencies to dictate your development schedule can be expensive. This becomes imperative in deciding what to use and when to roll your own.

In the next article, we’ll talk about how your opinions can become your dependencies because of the decisions they lead to.