Hacker News Reader

Comment by tomxor | Hacker News Reader

My default these days is to roll my own (at least within some predefined context), this is because I view each new dependency as a significant cost, so i'll invert my answer: For me to include an external dependency it must provide very relevant and high value to the project to outweigh it's inherent costs.. even if that is satisfied I feel like I should also trust the authors.

This attitude has basically eliminated unhappy surprises from external code for me. This is probably a disposition earned through developing mostly in the JavaScript community (I am now the polar opposite of the NPM duct tape developer, and I prefer flat dependency trees).

View on HN

This is interesting to me because I often see rolling my own X as having a higher cost than bringing in a dependency. Maybe this is due to a lack of experience on my part, so I’m curious what you all consider when evaluating the cost of a dependency?

My opinion: rolling your own does have a higher initial cost, but it can have a much lower long term cost. Consider the case where you need a very small modification to the dependency. In many cases that will require a much greater investment because you will now have to a) understand the dependency, b) make and test the change and c) support the change long term (unless it is folded into the mainline). Also consider the case where some dependency or specification changes (way too frequently) or there is a bug that you desperately need fixed. What do you do then? Technical debt. For me then, understanding the probability and consequences of events like that is important.

Yes this is my point, upfront cost for a dependency is obviously zero (well maybe not zero if you include the cost for learning someone elses interface and integrating it into your code), it's always later that you pay in unforeseen ways.

One thing I’ve gotten better at over the years is identifying the viability of off-the-shelf tools early on. If you minimize subpar tooling at the source, you can mitigate long-term frustration down the line.

> this is because I view each new dependency as a significant cost

I view lines of code that other people have to maintain as less costly than lines of code I have to maintain.

> I view lines of code that other people have to maintain as less costly than lines of code I have to maintain.

Initially... but they can break your lines of code in unforseen ways in the future, and when that happens it will be you maintaining those external lines of code, because no one else cares.

To make things worse external dependencies are often highly generalised and complex because they are trying to cater to more than your project, as a result you may incur the cost of those lines of code even if your project doesn't need them as you have to wade through them and accommodate them when things go wrong with the parts you care about.

I'm talking worst case, but the point is, you want to only use dependencies you trust, which usually means minimizing your total number of dependencies also.

>Initially...

Code reuse is initially harder, as you have to figure out the existing system, how to integrate with it, how to frame your problem in its terms, etc. This is usually slower than just writing the thing. It's over time, when other people/teams are contributing to and fixing bugs in the shared component, where you and the company are saving work vs. each team with a similar-shaped problem learning the same lessons independently.

Reply on news.ycombinator.com