Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cull your dependencies

tomrenner.com

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Cull your dependencies

#61

Post by layer8 »

smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

There’s a natural bias to prioritize near-term cost over long-term cost, which translates to there being a bias to just add yet another dependency. The advice is therefore to be aware of that bias and to actively work against it to counteract it. Of course, the involved trade-offs need to be considered to strike a good balance. If the stakeholders don’t enable you to strike such a balance, personally that would be an important reason to quit that situation, or to take care to not get into it in the first place.

Re: Cull your dependencies

#62

Post by bayesian_horse »

The assumption of 15-20 errors per 1k line of code can't hold for the most used libraries. Incidents like the Log4j mess are memorable because they are rare. I bet people have been crawling all over similar logging libraries for other platforms now, looking for similar problems.

Good luck not adding dependencies. What's the alternative? Maybe some of the dependencies can be avoided without cutting functionality. But really only by two methods: Either there is already another dependency doing the same work, or you implement it yourself. In the latter case, chances are that the code will be less mature.

Re: Cull your dependencies

#63

Post by bayesian_horse »

layer8 wrote: post #61
smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

There’s a natural bias to prioritize near-term cost over long-term cost, which translates to there being a bias to just add yet another dependency. The advice is therefore to be aware of that bias and to actively work against it to counteract it. Of course, the involved trade-offs need to be considered to strike a good balance. If the stakeholders don’t enable you to strike such a balance, personally that would be an…

Not everybody thinks that maintaining your own code is eventually cheaper and safer than adding a mature dependency.

Re: Cull your dependencies

#64

Post by bayesian_horse »

a15971 wrote: post #56
smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

It's not that '... developers ... are lazy, and prefer to write as few lines of code as possible, sticking rigidly to the principle of "not reinventing the wheel"'. They don't do that because they are lazy. They do that because of competitive pressure. In SW development, in most cases, particularly in enterprise development, "the fastest person wins". Whoever moves fast and delivers fast will get to do more projects…

Reinventing the wheel is also decidedly unfulfilling.

Re: Cull your dependencies

#65

Post by vlovich123 »

EdSchouten wrote: post #13

I don't think there's an issue with depending on libraries that are big. If the library is just a big bag of classes from which you cherry-pick the ones you need, then the extrapolation on the number of bugs as mentioned in the article under "By the numbers" is meaningless. Why care about bugs in code you don't use if it doesn't even end up getting linked into your program? In modern languages like Go or Rust, it wil…

Don’t be so sure. Large libraries often aren’t well-separated and so you end up not being able to strip as much as you intend (unless there’s an explicit design goal that’s somehow enforced to keep things in isolated components). If you can’t strip, that means there’s a dependency somewhere which means you may end up exercising code you didn’t intend. Log4j is an extreme example and generalizing from it to all libraries is bad engineering but paying attention to dependency graphs is a good idea even if people will continue to ignore the problem.

Re: Cull your dependencies

#66

Post by [deleted] »

bayesian_horse wrote: post #62

The assumption of 15-20 errors per 1k line of code can't hold for the most used libraries. Incidents like the Log4j mess are memorable because they are rare. I bet people have been crawling all over similar logging libraries for other platforms now, looking for similar problems. Good luck not adding dependencies. What's the alternative? Maybe some of the dependencies can be avoided without cutting functionality. But…

[deleted]

Re: Cull your dependencies

#67

Post by layer8 »

bayesian_horse wrote: post #63
layer8 wrote: post #61

Earlier quoted context omitted.

There’s a natural bias to prioritize near-term cost over long-term cost, which translates to there being a bias to just add yet another dependency. The advice is therefore to be aware of that bias and to actively work against it to counteract it. Of course, the involved trade-offs need to be considered to strike a good balance. If the stakeholders don’t enable you to strike such a balance, personally that would be an…

Not everybody thinks that maintaining your own code is eventually cheaper and safer than adding a mature dependency.

Nobody said that it would. You’re putting up a straw man.

Re: Cull your dependencies

#68

Post by bayesian_horse »

ChrisMarshallNY wrote: post #35
henrydark wrote: post #31

"15-50 bugs per 1000 lines of code" is weird. The model should discount on number of years that have passed since a line was written.

I'm pretty sure the log4j bug was many years old. Depending on the bug, it only takes one. There may be 14,999 non-serious bugs, and one Bad Bug. The other bugs just give the baddie some tall grass to hide in. I think that not using dependencies, as a general rule, is good starting point, but, like all these "hard and fast" rules, the proper answer is "it depends." I think that importing a 20KLoC JS library, so you c…

A specific example doesn't contradict the norm. Bug discovery is like a stochastic survival process. The more a line of code with a bug is tested, used or whatever, the higher the probability someone discovers the bug. This means the number of bugs decays with time and testing. This does not mean there are zero bugs in old code.

Re: Cull your dependencies

#69

Post by marginalia_nu »

Veuxdo wrote: post #3

"Invented here syndrome" is a real and pernicious problem.

I think it probably depends on the size of organization.

NIH is a problem in old and large organizations, which actually have a large roster of homegrown solutions.

On the flip side, I feel a lot of smaller organizations have the opposite problem, like a weird phobia against nontrivial code. Like you need a special license to implement a bespoke data structure or some graph algorithm.

Post reply on HN