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

71–80 of 132 posts

Re: Cull your dependencies

#71

Post by dgb23 »

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…

That’s assuming you move faster with a given dependency and that there isn’t some non obvious mismatch between it and what you try to accomplish.

Re: Cull your dependencies

#72

Post by at_a_remove »

I think culling dependencies is smart, but the selection of which to cull (or at least consider) is a high art.

Does this dependency generate a lot of vulnerability issues? How stable is it? If it has a high change velocity, how stable is the API or whatever portion you use?

At a previous job, someone was advocating for this repository software which I shall not name. I did a Visio diagram of all of the major things on which it depended: Solr, Ruby on Rails, and so forth. It looked like the Tower of Babel. I then colored the blocks in this tower in if that project was written in a programming language we didn't have expertise in.

Well, they went with it anyway. The job is in the rearview mirror but consultants continue to work on this project.

Frankly, the dependencies in the project alone were enough that one would need a reasonably-sized team to even consider it, much less the paltry number of bodies we had to throw at the problem in the middle of all of our other tasks. Don't get me wrong -- you can build amazing things by stacking together predefined blocks, but life is always going to try to Jenga that tower you have created.

Re: Cull your dependencies

#74

Post by jamal-kumar »

mschuster91 wrote: post #37
jamal-kumar wrote: post #25

Earlier quoted context omitted.

Is the health safety and wellness of your user base important to you? "Who cares" matters when your userbase gets fucked over because you didn't.

To us developers, maybe. To our managers? Definitely not. As long as the GDPR fines are cheaper than the alternative, no one will care.

I'm really glad I don't work in a company like that.

Re: Cull your dependencies

#75

Post by teddyh »

smarx007 wrote: post #40
pjbster wrote: post #9

I was immediately reminded of this gem from https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-... “You know their motto? ‘Find the dependencies — and eliminate them.’ They’ll never go for something with so many dependencies.”

> If you have customers, never outsource customer service. Hopefully, every business has customers?

Yes, exactly. That’s the point.

Re: Cull your dependencies

#76

Post by cvccvroomvroom »

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.

Re: Cull your dependencies

#77

Post by kerblang »

I think a lot of naysayers here are missing the point:

> The underlying Log4J library is 168,000 lines of code.

I would find it difficult to invent a logging system so exotic, even if somebody paid me to. People are ignoring the incredible size of their real footprint. My 4000-line microservice is actually my 3,000,000-line macroservice and every single one of those lines is a potential trouble spot for security bugs and myriad other issues - memory issues, startup issues, compatibility issues, on and on...

In fact I would argue that confusion about exotic open source frameworks leads to wrong assumptions in which people figure "oh I think the framework takes care of that" when in fact they have a massive problem they don't understand. Even when the security bug is documented it's incredibly hard to figure out which releases are affected, which releases are fixed, and so on - of course it shouldn't be, but it always is.

You can try to argue that "I'm only using this one part and I should be excused!" but that never works in practice. One function call can traverse the world before returning. Many frameworks quietly do all sorts of things during bootup without one's knowledge - it's sometimes mystifying how the dang thing managed to wake itself up and unleash havoc in the first place.

Re: Cull your dependencies

#78

Post by cvccvroomvroom »

vlovich123 wrote: post #65
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 librar…

OpenSSL is everything and the kitchen sink feature creep. Their development and architecture methodology are nil.

Re: Cull your dependencies

#79

Post by dgb23 »

smarx007 wrote: post #40
pjbster wrote: post #9

I was immediately reminded of this gem from https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-... “You know their motto? ‘Find the dependencies — and eliminate them.’ They’ll never go for something with so many dependencies.”

> If you have customers, never outsource customer service. Hopefully, every business has customers?

I think that’s the joke.

Re: Cull your dependencies

#80

Post by jamal-kumar »

dahfizz wrote: post #38
jamal-kumar wrote: post #19

The first thing I look for when starting a new project is if I can't be served by the standard library in whatever lang I'm using, to find dependencies that don't also depend on a bunch of code that I will have to indirectly depend on. The code I wrote like that still runs like ten years later without much problems having to update it. The code I worked on which depended on whatever flavor of the year framework peopl…

Absolutely. This is where the real dependency bloat in ecosystems like npm come up. You may only include a handful of reasonable dependencies, but each of those have dozens of their own dependencies, and so on and so on.

I'm super allergic to the nodejs ecosystem, it's so bad.

I also get away in my professional life using it for pretty much nothing and it's great. There's a reason Ryan Dahl moved on to Deno.

People who think it's somehow necessary or integral to getting a website going are deluded hypebeasts.

Post reply on HN