Adding new dependencies to a codebase is a net positive until it’s not. The added leverage of picking up an off-the-shelf solution eventually gives way to dependency hell—fixing breaking changes, incompatibilities between things, security issues, and so on.
Most technical decisions about dependencies happens early on in development and sticks around forever. Being judicious and deliberately selecting dependencies for longevity (especially frameworks) can keep the churn down later.
After the initial dependencies are selected, the default strategy to be to not add anymore. That doesn’t mean never add new dependencies, just that it should be the default. It means more closely interogating each new addition more carefully and acknowledging the trade-off each time.
See also:
- Adding dependencies is a right-half-plane zero
- The JavaScript ecosystem is dependencies heavy and you probably won’t get away from it, trading off ease of adding dependencies over bundle size
Links to this note
-
There Is No Software Maintenance
In There Is No Software Maintenance by Henrik Warne, the author argues that software maintenance is just product development. Since software is never “done”, all of the things we call maintenance such as bug fixes and improvements are feature enhancements and iterating on the original feature.