"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.
Cull your dependencies
31–40 of 132 posts
Re: Cull your dependencies
#32The argument seems a bit myopic. The author is talking about errors and vulnerabilities found in libraries while ignoring those same factors in bespoke code. At best that's a "security through obscurity" scheme.
I'm not sure they are ignoring those factors in their own code. It's more a case that the libraries might be increasing their risk factor by an order of magnitude or more.
Only if you use a small percentage of the functionality. If the dependency is maintained (not all are!) there is a good chance someone else discovered many of the bugs, the the per bugs per line of code metric should be much lower. And the dependency probably has some features you wish existed but can't justify the effort to write.
It is about trade offs. Is the time/money saved and the additional features gained worth the cost that some of features you don't use may result in more bugs that affect you in some way. For the most part I'd say no: I can write my own whatever, but that too will have bugs, and I need to fix all of them. I work with people who disagree with me on this one, and so we have a lot of pain maintaining code we wrote ourselves that isn't as good as a library I could have downloaded. Or in some case code that is already on our system - We have 6 different logging frameworks in one project, 3 we wrote in house, this is a big mess.
Re: Cull your dependencies
#33> which at a conservative estimate gets us to 1M lines of code in the imported packages. This is roughly the size of an entire operating system.
Operating Systems are way bigger than 1M lines of code. Even in the link he gives, the smallest "OS" is 2.4 million lines, and that's actually the Linux kernel from 2001. The true smallest OS is Windows NT in that link, at 5 million lines of code iirc.
Don't make false comparisons. An operating system hasn't been anywhere near 1M lines of code for almost 30 years. They are now over 500M lines of code! The kernels alone are way larger than 1M lines of code. If you're going to make a comparison, use a real comparison instead of making stuff up and then providing a link that immediately disproves yourself.
Re: Cull your dependencies
#34It 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…
Wow okay I'd be highly interested in such an analyzer as well.
Re: Cull your dependencies
#35"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 can animate a single window opening is maybe not such a good idea, but it may be worth it, if you plan to animate dozens of window openings. Even then, it may be a good idea to have one of your more experienced geeks take some time to write a utility that gets reused throughout the project.
I use a lot of dependencies. I believe that modular design is an important component of managing complexity and ensuring high Quality.
But, the caveat is that I have written almost every dependency I use. I write each one as a standalone project, complete with heavy-duty documentation, and lots of testing (Usually, the testing code eclipses the actual implementation code).
Because of this, I can write a pretty damn robust application in just hours.
If anyone is interested in seeing what I mean (I don't expect many takers), they can always browse some of the modules in my various repos.
Re: Cull your dependencies
#36The argument seems a bit myopic. The author is talking about errors and vulnerabilities found in libraries while ignoring those same factors in bespoke code. At best that's a "security through obscurity" scheme.
The problem with libraries is that they often contain so much functionality while you yourself might only need a single thing (and don't even realise all the stuff the library is able to do). Whenever I had to patch systems due to some vulnerability my first thought was "Wait, why the hell is a library even able to do that ?"
The log4j2 vulnerability is probably a good example of this. How many systems running log4j2 actually uses the JNDI functionality that led to the exploit?
Re: Cull your dependencies
#37The truth is that the world generally doesn't give a shit about software quality. Developers are expensive and business models shoddy. You have to be quick, otherwise the competition makes the race. I for my part have given up and go with the flow. Who cares if Hibernate creates a million queries in the background. Hey, it works, so ship it!
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.
Re: Cull your dependencies
#38The 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.
Re: Cull your dependencies
#39It is a fine balance. Good luck doing that in JS which has zero standard library on the browser. C#, for example is in better shape and you can do a lot before you reach for nuget for anything outside of Microsoft. I prefer to not import tiny libraries but adopt the code into the codebase.
If it weren’t for C#, we’d have a much harder time doing business with our banking customers.
When it comes to vendor due diligence time, we only have to write a single 3rd party’s name into that box. Every one of our customers mutually trusts Microsoft too.
We’ve been at it for over 7 years now and we still only “depend” on Microsoft. Even stuff like SQLite falls under the Microsoft.Data.* scope these days.
Re: Cull your dependencies
#40I 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?