But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. These are costs which, for the most part, apply to code whether you import it or write it yourself.
In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixed by other people.
But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden.
Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented.
If those inherent risks are also significant and you can mitigate them by importing a good implementation of the required functionality instead of building your own, that can be a trade-off worth making. It would rarely be a good idea to use a home-grown encryption algorithm, for example.
However, if we’re talking about simple functionality that you could write yourself in minutes anyway and where you would have to try quite hard to create a significant vulnerability or to need much ongoing maintenance, the costs introduced by importing the functionality instead will often be disproportionate.
> Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented.
Why? What is different about an external dependency that creates this risks in excess of writing it myself? To me, these risks all seem less when importing then writing it myself.
No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it.
Why? What is different about an external dependency that creates this risks in excess of writing it myself?
You seem to be answering your own question there: the extra risk is because you aren’t writing it yourself. The extra risk is because you are trusting an external source to provide what it says it will and that whatever it provides will then work as described.
As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs.
No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it.
I can see no basis for that assumption in the world of JS and NPM. Anyone can set up an NPM account and then push code for public consumption. Giants like react have been brought down by tiny packages like left-pad.
And yet, I could have written the code for left-pad, complete with a little test suite, in less time than it has taken me to write this HN comment, and probably so could a million other people. How much collective development time do you think was lost because no-one at Facebook actually did?
As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs.
Fair enough, most of those are legitimately risks of external code that doesn't apply to internal code. However, I object to object that nobody writes bug-free code so the possibility of my chosen package having bugs isn't such a case.
> I can see no basis for that assumption in the world of JS and NPM
I overstated my point there.
> Giants like react have been brought down by tiny packages like left-pad.
Its a nit-pick, but react wasn't broken by left-pad. Babel was broken which is almost always used with react.
In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixed by other people.