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

81–90 of 132 posts

Re: Cull your dependencies

#81

Post by cvccvroomvroom »

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,…

Build & support vs. buy or use

The cost of maintaining and supporting beyond simple cryptographic primitives is too steep for most projects.

Re: Cull your dependencies

#83

Post by koblas »

wcedmisten wrote: post #4

It would be nice if there were a way to quantify the value of your dependencies. If you have a dependency with 1,000 LoC and your application is utilizing 800 of them, that seems like a good reason to use the dependency. You're (hopefully) getting unit tests, documentation, and public exposure of the code (bugfix opportunities) for "free" If you have a dependency with 1,000,000 LoC and you only need 1,000, that indic…

This makes me think about the quality of the dependancy. If you could evaluate packages for things like:

* Test coverage -- that's not a metric on NPM * Code practices -- what's the review history * Issue velocity -- hard metric, lots of features vs fixes * Hygiene -- for many languages is typing enforced / validated

I'm sure there are lots of other metrics, but so many times you're just evaluating two packages based on "star count" or "npm installs".

Re: Cull your dependencies

#84

Post by kixiQu »

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…

> Why care about bugs in code you don't use if it doesn't even end up getting linked into your program?

If things are segmented in ways such that you can automatically tell that you're not impacted by a bug, cool.

A lot of log4j emergency deployment pain in BigCos had to do with the limitations of tools that could discern whether you weren't impacted, because security vulnerabilities of that magnitude aren't an area where "probably not" is good enough. I wouldn't really be comfortable with "it's fine that my uses a framework with massive unpatched vulnerabilities, they're very careful to hand-pick classes to import that are safe".

(modulo the security of real world banks/surgeons being, uh, less than ideal, and all of my PII probably being accessible from some wordpress endpoint somewhere)

Re: Cull your dependencies

#85

Post by bertr4nd »

cvccvroomvroom wrote: post #76
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…

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

But what’s the back pressure to this advice? If I need to multiply matrices should I write my own to avoid including MKL BLAS? What’s the heuristic that determines when a dependency is worthwhile?

Re: Cull your dependencies

#86

Post by stared »

There is always balance with reinventing the wheel. Plus, a custom library often gives way more technical debt than a standard one. Less battle-tested, fewer tutorials, very often a lot of idiosyncrasies.

A few times, we were going a different route:

We use libraries if needed, but after some time, we pruned ones from which we used only a few functions/classes. That way, there is (almost) no delay in development, but there is this process to keep things clean.

The converse is much more challenging. Writing a lot of code then discovering one is effectively reimplementing an existing library, which took quite a few person-years.

Re: Cull your dependencies

#87

Post by twic »

netr0ute wrote: post #49
twic wrote: post #48

Earlier quoted context omitted.

Rather than reviewing any licenses, you should incorporate a license check in your build. I did this in a Gradle project recently, and it was pretty easy: https://hg.sr.ht/~twic/lambda-property-matcher/rev/53ef7eb30...

Why make it so difficult? Just make your project AGPL and stop worrying about other OSS license compatibility.

Because i'd like my software to be useful to normal people.

Re: Cull your dependencies

#88

Post by stared »

fmajid wrote: post #53
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,…

And it will cost vital time to market. I am very conservative about introducing dependencies but there is a reason why they are proliferating and it is not just developer laziness. Here’s a very good take from Joel Spolsky: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-... Not everyone has the resources of a Microsoft, though.

I agree that for core parts it matters. But quoting the post by Joel:

"If you’re developing a computer game where the plot is your competitive advantage, it’s OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own."

Re: Cull your dependencies

#90

Post by dosethree »

koblas wrote: post #83
wcedmisten wrote: post #4

It would be nice if there were a way to quantify the value of your dependencies. If you have a dependency with 1,000 LoC and your application is utilizing 800 of them, that seems like a good reason to use the dependency. You're (hopefully) getting unit tests, documentation, and public exposure of the code (bugfix opportunities) for "free" If you have a dependency with 1,000,000 LoC and you only need 1,000, that indic…

This makes me think about the quality of the dependancy. If you could evaluate packages for things like: * Test coverage -- that's not a metric on NPM * Code practices -- what's the review history * Issue velocity -- hard metric, lots of features vs fixes * Hygiene -- for many languages is typing enforced / validated I'm sure there are lots of other metrics, but so many times you're just evaluating two packages based…

Factors for me are: 1. how hard will it be to remove/replace this package in the future? how much coupling does it introduce? 2. how likely will it be that this is deprecated/unmaintained in the future
Post reply on HN