Skip to content
All insights
EngineeringMaintenance5 min read

The dependency you can't update

Every codebase eventually has one. The library that's three major versions behind, deeply embedded, and nobody dares touch.

Five years in, every codebase has the dependency that's stuck. Three major versions behind, used everywhere, breaking changes in the upgrade path, and no engineer wanting to be the one who tries. The team negotiates around it like it's a chemical leak.

Why it sticks

Each year of deferral makes the upgrade larger. Each new feature that quietly depends on the current behavior adds another constraint. Nobody is wrong to defer. Everyone is wrong to defer indefinitely.

How to actually do it

  • Split it into smaller upgrades — one major version at a time, even if it takes a year.
  • Treat it as a quarterly priority, not a side project.
  • Build a thin compatibility layer so app code can keep using the old shape while the library updates underneath.
  • Budget for it — give engineers explicit permission to spend time on it.
The dependency you can't update will eventually update you — usually at the worst possible time.

Most operations are behind where they could be.

Book a strategy call. We'll map one system worth automating in the next 30 days. No pitch, just the plan.