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, security issues, and so on.
Most technical decisions about dependencies happen early on in development and stick 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 should be to not add more. That doesn’t mean never add new dependencies, just that it should be the default. It means closely interrogating 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.
-
As software grows, patterns and practices naturally evolve. Inevitably, someone comes to the conclusion that a change should happen and code should be migrated to the new thing.