Hacker News Reader

Comment by f4c39012 | Hacker News Reader

i can think of two reasons for using a third-party dependency

1) a dependency on a third-party service provider that publishes the dependency. So long as that service provider is current, the dependency should be maintained 2) short-cut to code i don't want to write

I have no arguments with (1), there's a business reason and the lifecycles should match. However, I should still expect major version breaking changes in order to keep my application running. For (2), the wins are less clear, more dependenent on the perceived complexity of what I can avoid writing.

Taking on any kind of dependency means that someone else can dictate when I need to spend time updating and testing changes that don't add anything to my product. Taking on a third-party dependency is always taking on a responsibility to maintain a codebase or the risk of not doing so.

View on HN

I would argue that 2 is the much more important reason. A dependency is worth it if it saves you a lot of time building the same thing. For example, if you wanted to ship a general computing device, you should probably run Linux on it rather than building your own OS from scratch, because you'll save literal years of work. Even if Linux had stopped being maintained, this would still be the right call compared to building your own (of course, it would be even better to choose some other OS still being actively maintained, if any is available).

I wish we could have this discussion without going into exaggerated extremes like "Linux". The OS rarely gets into discussions of rewriting dependencies.

I recently had to rewrite a table component and it took about an hour with extra performance and it became faster-to-use and tailored to my company's needs. One hour, give or take! With measurable performance improvements, and it's simpler to use for our use cases, and it doesn't prevent anyone from using the old one.

Comparing one-hour or even one-day work with rewriting Linux is ridiculous fear-mongering.

But this is exactly my point. Some dependencies don't actually save you any time, they're trivial to write yourself, so there is no point in getting them (perhaps the most absurd and infamous example of this being left-pad). Other dependencies are extremely hard to write, so finding a version someone else built, even if they are not maintaining it anymore, is worth it.

Theres a third one, when it comes to compliance and security tools, you don't want to build it even if you can because.

1. It is a liability

2. There is trust deficit during audit and other events. If audits are internal only sure you can build it but when it is 3rd party audited, auditors often know the product and familiar with the features.

> auditors often know the product and familiar with the features.

or what if you chose a dependency for which this auditor is unfamiliar with, and so it takes even longer (where as if you NIH, you'd have the full source and thus can give the auditors the materials to audit).

I am not sure most auditors work on that level of detail. If it is a library they don't consider audited yet, they might just call it a day and make a statement about your code excluding the dependencies they are not familiar with. Otherwise you would have to pay for all third party dependency audits, which no one else paid for yet or the auditor is not aware of someone else having audited already.

You are right. Thats not the level they often go to.

I have also seen this narrative. If things go south in the org. btw we were using product A for doing our workflows, that replaced if with product B for the same, now everything is going to better.

This is where using boring languages like Go and Java come into their own: less frequent breaking changes.

There are some languages where communities aim for libraries to be stable for several months, and there’s others that think in terms of a decade or longer.

There is another solution which is to just retain the source for your dependencies and bring them in-house if needed. You still may need to abide by licenses, and many things shouldn’t need to rely on external deps, but I’ve seen a lot of wasted time that continues because we came up with our own way of doing something that others do better, and that can be difficult to get rid of because of unwarranted team pride or familiarity in the homegrown code or not wanting to trust the lone dev that says try this instead.

Most important reasons imo:

1) even though reality has proven us wrong time and time again, we can just not look at the dependency too closely and just act as if it's written and maintained by competent, caring people and is of highest quality. No worries!

2) in case shit hits the fan, let's assume worst case and there is a vuln in the dep and you get hacked... It's somebody else's fault! \o/

> 2) in case shit hits the fan... It's somebody else's fault!

A contrived example but, good luck explaining to the lawyers that openssl had this bug that caused all your customer data to leak and your company is being sued. If your motto for dependencies are “we can just not look at the dependency too closely and just act as if it's written and maintained by competent…” I’m reasonably sure someone is getting fired in that situation if it doesn’t sink the entire company.

Move fast and break things isn’t exactly a viable strategy in all industries.

Now as I said openssl was a contrived example but what if instead it was your ORM that didn’t use templated queries but rather just did string interpolation and there was an SQL injection attack. Considering this is still one if the most popular vulnerabilities on the web someone is messing stuff up somewhere and you are blindly like hoping it isn’t in the 10k lines of ORM library you pulled in instead.

Reply on news.ycombinator.com