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, 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:

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

  • Migrations Are Mini Rewrites

    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.