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.