Making Progress on Dependency Management in Manila

Dear Sloan,

I’m a newer developer, and am experiencing the dreaded “dependency hell” for the first time. My team is starting to manage dependencies better, but I would love some tips from you on how to efficiently and effectively handle our dependency management strategy!

Signed,

Making Progress on Dependency Management in Manila

Hello there!

I am so glad to hear that you are looking to make progress with how you and your team handles the management of dependencies. It’s a tricky business migrating dependencies, so let’s dive into what makes a good dependency management strategy.

Gauging Your Current Dependency Management Behavior

There is a section in the 2022 State of the Software Supply Chain Report that explains a few patterns of behavior when it comes to dependency management. It can be helpful to assess where your team is at and where you can go from there.

These general patterns are as follows:

Teams Living in Disarray
- Teams living in disarray are not using automated solutions to aid in dependency management, and tend to be very reactive in their updates. This behavior is reactive, doesn’t scale, and carries increased tech debt and security risk.
Teams Living on the Edge
- These teams are using simple automation to drive automatic dependency updates to the latest version. This leaves some security gaps, as updates aren’t necessarily optimal and frequent updates can lead to rework and security vulnerabilities.
Teams Living Close to the Edge
- These teams are using automated solutions to recommend necessary updates, providing a layer of security protection without upgrading too frequently unnecessarily. Teams with this behavior have a proactive and scalable approach.
Optimal
- These are teams that follow the below eight rules when they upgrade, and are working the most efficiently when it comes to managing dependencies.

Eight Rules for Upgrading to the Optimal Version

There are two kinds of choices that are key in avoiding making bad decisions when upgrading components: objectively bad choices and subjectively bad choices. Following these rules will aid you and your team in managing dependencies optimally.

Avoid Objectively Bad Choices

There are four rules here, and those are:

Don’t choose an alpha, beta, milestone, release candidate, etc. version.
Don’t upgrade to a vulnerable version.
Upgrade to a lower risk severity if your current version is vulnerable.
When a component is published twice in close succession, choose the later version.

Avoid Subjectively Bad Choices

There are four rules here as well, and those are:

Choose a migration path (from version to version) others have chosen.
Choose a version that minimizes breaking code changes.
Choose a version that the majority of the population is using.
If all else is tied, choose the newest version.

Being Balanced and Proactive is Key

You may have heard “software ages like milk, not wine” before, and it’s true! If you’ve ever opened your refrigerator to some well past-date perishables, you’ll remember the importance of checking every now and again for food that isn’t fresh any longer. At the same time, you also don’t want to replace food that isn’t “bad” yet, because that’s wasteful of both food and the time and money to replace food that is still fresh enough to eat.

So this leaves us with the need to ensure that our dependencies are secure, ideally with automated solutions, without upgrading unnecessarily. The eight rules for updating to the optimal version will help you and your team to find the right balance.

We have some additional resources for you to learn about dependency management, including our Beginner’s Guide to Package and Dependency Management and The Definitive Guide to Open-Source Component Best Practices. Is there anything else that you would recommend to those trying to improve their dependency management strategy? Let us know in the comments below.

Catch you next time,
Sloan