The Default Strategy for Dependencies Should Be to Not Add More

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:

  • 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.