You have a limited amount of time to spend on software maintenance.

It seems counterintuitive to spend it on things that aren't broken.

But the same libraries you use to get off the ground quickly can hold you back in the long term...

Often right when you need them the most.

A harder upgrade path when you need it

There's no wake up call like discovering a capability you need is within arm's reach.

All you need to do is upgrade one dependency...

That's when you find that you need to upgrade many dependencies to support that single upgrade.

This cost feels like a margin call on technical debt.

The things you depend on are more likely to change

I've encountered dependencies where:

• The exact version being relied on has been removed

• It is no longer maintained at all

• There is a ticking clock on upgrading

One of the principles of Object Oriented code applies here: rely on things that change less often then you.

Become out of step with your industry

It feels bad to work on code without the latest affordances.

You'll know that there is a simple solution a few major versions ahead in your framework, but the upgrade would be harder than accomplishing the task at hand.

All while your adding more costs to upgrading code.

Security

This may be the most obvious cost, but staying will behind on software dependencies can open your software up to vulnerabilities that would otherwise not worry you.

I don't advocate for riding the bleeding edge for the libraries your software depends on.

Upgrading regularly will keep your software nimble and safe, and your developers happier.