| not usually, because: 1. usually a library has a wider range of features than you need. So you don't have to rewrite the whole library, just the bits you need, and you end up writing much less code because don't have to integrate the bits you need with the bits you don't need. 2. you do have to spend a lot of time understanding the interface of the imported library and writing integration code to use it correctly. 3. (as others have said) there's a lot of time spent auditing the library (and all its dependencies) to make sure it's not doing bad things. And that auditing work needs to be repeated every time any dependency of the library updates a version.
This is especially important if you're doing anything with customer information involved - you're liable if you import a library that imports a dependency that quietly sends your customer's personal information to a url in Russia. 4. you may have to make architectural compromises to fit the library in; it might not support concurrent access, or idempotent calls, and that may cause more time loss in the long run than just writing what you need yourself. 5. the library becomes a black box, and your code becomes plumbing connecting the black boxes together. Trying to debug your application, or improve performance, or make it more robust, is impossible because you can't change any of the black boxes and your plumbing code does nothing important. that's most of why I prefer to roll my own code rather than import a dependency in most cases (crypto being the notable exception). |