I like to think of this as a dependency cost. Adding a library may "relieve" implementation cost, but adds a dependency cost (ie. finding+evaluating dependencie

I like to think of this as a dependency cost. Adding a library may "relieve" implementation cost, but adds a dependency cost (ie. finding+evaluating dependencies, integrating and maintaining the dependency, testing the dependency and so on). This cost varies a lot, for example a library to left pad a string may be easily replaced, but if you choose a library to implement some on-disk format, then that can cement things in. If the library becomes unsupported one very well may end up maintaining it alone, for example. In the more general case more issues are attached: choosing a deployment stack, a documentation or translation tool etc. can result in decisions that are essentially set in stone. These also tend to be composed from multiple tools, leaving more wiggle room. Deployment for example might be done with AWS and Ansible on the higher levels, but use in-house tooling for figuring out the details. Similar arguments apply to code de-duplication and DRY: de-duplicating code isn't free, and not always the right thing to do. See also: http://blog.liw.fi/posts/dependency-cost/ http://blog.liw.fi/posts/dependency-cost/