A growing number of engineering teams are doing something unusual for the industry: quietly ripping dependencies out of mature products, shrinking codebases that have grown for a decade rather than adding to them.
The motivation isn't nostalgia for simpler code. It's maintenance cost — every dependency is a future security patch, a future breaking change, a future engineer who has to learn a library just to fix one bug.
Subtraction as a strategy
Teams doing this report a real, if unglamorous, payoff: fewer 2 a.m. incidents traced to a third-party library update, faster onboarding for new engineers, and a codebase that's actually possible to reason about end to end.
It isn't free. Removing a dependency usually means rebuilding a smaller version of just the piece you need, which takes real engineering time upfront. The teams doing it argue that cost is smaller than the compounding cost of never doing it at all.