There are many ways to incur technical debt but the broadest reason it both exists and persists is that most applications are old and most software developers are working on new things. In an ideal world, agile organizations would have very little technical debt because they should always return to their code and improve it. But in the real world, the fast pace of continuous rollouts means agile organizations can be especially prone to collecting large amounts of technical debt. And, sure, sometimes that debt can even be a good investment, but it’s still a debt, and some debts simply need to be paid.
Some sources of technical debt, including architecture, design, and documentation deficiencies, can only be addressed through a manual process of reviewing and refactoring. But there is a source of technical debt that has an automated solution: outdated dependencies. With such a large percentage of modern codebases being third-party software, aging dependencies can add crippling amounts of technical debt to your projects. And, over time, once you get too far into that debt, it can be nearly impossible to climb out without major remediation, making the addition of new features extremely difficult. It’s easy to update from version 1 to version 1.1, and even version 1 to version 3 or 4 is usually possible. But version 1 to version 20? Not so simple.
Older code is a large target simply because there’s more of it and exploits have already been published. Most vulnerabilities that have been found in older versions of open source software have already been fixed in newer versions, which is great, but only if you’re on the newer version. Naturally, our focus skews towards security debt issues, but that’s only one perspective. From a non-security perspective, everything is harder: your quality, your reliability, and the basics of what you’re making become increasingly difficult if you don’t stay up to date.
Like the occasional slice of pizza or blowing off a workout, a little dependency-related technical debt usually won’t do much harm. But the longer you go without eating healthy and exercising, the worse things get. When your technical debt gets too big and your dependency health too far gone, you can be looking at the software equivalent of massive heart failure or even death. Once you’ve reached that point, it can be difficult if not impossible (not to mention costly) to reverse course, but it’s not all that difficult to avoid it altogether simply by updating on a regular basis. Of course, you have to actually make sure it gets done. It’s not very difficult to put off or altogether avoid updating, especially when it’s a manual process. As with preventive health for your body, preventive health for your software is always more likely to be achieved when it’s automatic and built into your processes and daily routine.
Developers are typically happy to have the latest versions of open source packages, if, and it’s a big if, those versions won’t break their code. Most updates are minor and unlikely to cause any problems, but you still have to remember to get them. Consumers rarely have to deal with problems like apps not working because they don’t have the right version of iOS or Android; our phones update automatically. Developers building new things into existence don’t have that same luxury.
What they do now have at their disposal is pretty powerful, though. Dependency management tools, like Renovate, allow developers to keep dependencies up to date easily by automating, scheduling, and grouping pull requests. An open source tool with a large number of users, Renovate also compiles crowdsourced information to give developers a merge confidence score so they can determine at a glance the likelihood that an update will break their code without having to comb through the release notes.
Making dependency health easy and painless for every developer makes a huge impact across an organization and across time. In the long term, you can avoid a lot of technical debt without much extra thought, time, or effort. It’s true that in many ways we’re talking about avoidance of debt rather than true reduction of existing debt. But even if you haven’t touched your code in five years, there are still some updates that will work and it’s worth using a dependency management tool like Renovate to figure out which ones they are. There’s an ancient saying (translated from FORTRAN, probably) that goes, “The best time to update your dependencies was five years ago. The second best time is today.”
So there’s no time to waste and no point in delaying. Dependency management can do a fantastic job of helping you tackle some older technical debt but its real value is in all of the technical debt it helps you avoid. If you’re not already requiring your developers to keep up with updates, it’s time to start. Your future self will thank you.