The average codebase is now 50% dependencies — is this sustainable?
Posted by Legitimate_Sun1783@reddit | programming | View on Reddit | 287 comments
I saw an internal report showing that most projects spend more effort patching dependencies than writing application logic.
Is “build less, depend more” reaching a breaking point?
wolfy-j@reddit
Wait till you hear what actually executes your codebase, it's dependencies all the way down.
ILikeCutePuppies@reddit
True, technically even the OS file system with the code file in it is a dependency itself.
I think its a matter of how reliable we think a dependency is.
wrosecrans@reddit
Yeah, 50% is an insane undercount that implies somebody has no idea how much code they are actually depending on underneath it.
I'll just write 1000 lines of Javascript, complain about 2000 lines of dependencies, ignore 100,000 lines of transitive dependencies and maybe a million lines of build system and test tooling, ignore millions of lines of C++ V8 related Javascript runtime and the roughly infinity dependencies it has if you've ever tried building Chromium from source, and maybe billions of lines of broader toolchain and OS ecosystem code, then stick it in some opaque serverless cloud infrastructure, then hope that by some sort of magic there are no firmware bugs in any of the storage or network devices so I can ignore the fact that those are even programmable...
There's a catastrophe of complexity and legacy in modern stacks, and even the specialist programmers writing blog posts about the complexity aren't even willing to vaguely nod in the direction of the most overwhelming piles of it.
Sigmatics@reddit
I don't think it's fair to count tools that you use to build your software as "code". Sure, you depend on them to build your software, but it's not "part" of the software.
wrosecrans@reddit
I dunno, I've definitely had issues where CMake grabbed a library with the wrong ABI because of a bug in the shipped find code, and it wound up linking and seeming to work for simple functions but blew up when passing STL or complex types over a call boundary. In C++, your STL implementation is generally bundled with the toolchain. Even for minimal C code with "no (visible) dependencies" like the STL you need to link to either libgcc or msvcrt to get the implementation of __init or whatever that sets up the stack and calls main and that needs to exist at runtime and be a thing you are careful about shipping properly.
The code has huge effects on what your final shipped application is and does. If there's a compiler bug, you are still stuck trying to figure out why your program is crashing. If your users can wind up filing a bug report about it and you wind up having to fix it, it's code you depend on and need to be thinking about at some point.
loup-vaillant@reddit
Careful how you count. If all you care about is one single app, sure, the dependencies likely dwarf it by orders of magnitude. Even my "zero" dependencies cryptographic library requires a C compiler for instance.
On a global scale however, it might be interesting to avoid double counting. Typical third party dependencies have many users. Dozens, hundreds, in some cases millions. To take but one example, there is probably much less code in Electron itself (including all its transitive dependencies), than the sum of Electron application code — because there are quite a few Electron apps out there. (This is in no way an endorsement of Electron by the way.)
When you compare how much code lies at the leaves, and how much code is used as a dependency, the proportion may not be as skewed as it would be if you were looking at each application separately.
I still agree with your main point though. We’ve gone high on dependencies, the madness has to stop. (Note: the only way I’ll ever write a web app will be under duress, and even then I’ll try my best to stay away from web tech — at the very least on the server side.)
wrosecrans@reddit
I get what you are saying. But I can still get bitten by all of that code, so the fact that it has many users and you can apply a sort of "discount rate" on the complexity when taking a global view isn't going to reduce the number of things that can go wrong on whatever specific application I am working on.
In my time, I've had to spend time hunting down compiler bugs, buffer overflows in the Perl runtime, problems in a Lua runtime, do custom builds of Chromium, dig into the XFS implementation in the Linux kernel, and hunt data corruption because at a large enough scale you will occasionally have multiple bit flips that survive TCP's checksums.
On none of those bad days could I just tell me boss "Oh, that bug doesn't count, because a lot of people use it." I still had users effected by it, and I still had to get it fixed. The complexity was still there and could still cause all sorts of wildly unintuitive trouble, and I was the one left holding the bag no matter how you count it.
loup-vaillant@reddit
Well, you’re right, that buffer overflow in the Perl runtime isn’t going to fix itself. Bug count doesn’t automatically decrease as the number of users increases.
On the other hand, I think it totally would decrease as the number of paying customers increase. Especially if the payment comes with a support contract, or some form of liability. But that’s not the root we took, and so we got Heartbleed (among many others).
Personally I absolutely hate dealing with the kind of problems you describe. That’s one of my reasons to chose my dependencies very carefully. And in general, I’d rather write up to a hundred lines of code than take on a third party library — even a well written one.
WellHung67@reddit
Quit depending on physics the maintainer has left us long ago and it’s running on fumes, gonna be subsumed into the borg soon
gimpwiz@reddit
Abandonware with absolutely zero documentation from either the original author or subsequent maintainers, yet every pointy-haired boss demands we somehow make it work for completely disparate and unrelated needs, on a tight schedule, with impact to health and safety in addition to financial impact. Complete bullshit.
Sage2050@reddit
14 billion bug free years though
Kered13@reddit
What are you talking about? There are an estimated 10 quintillion bugs. Hardly sounds like a robust product.
CramNBL@reddit
Quantum tunneling is a bug.
Kered13@reddit
It was originally, but everything has come to depend so much on it that it's considered a feature.
CramNBL@reddit
So much physics debt... It might be time to reconsider vacuum stability and go for world v2
loup-vaillant@reddit
I’m finally at a point in my career when I can just say "nope". If it’s harmful enough, or even pointless enough, I won’t do it. Fire me if you have to. That’s okay. I’m not hungry yet.
(I will however explain in excruciating detail why what I’m being asked to do is pointless or harmful. Always give them a chance first.)
gob_magic@reddit
All the way down. Relevant xkcd: https://www.explainxkcd.com/wiki/index.php/2347:_Dependency
dislexi@reddit
Yeah I hear some programmers run their code on hardware they didn’t build themselves.
Legitimate_Sun1783@reddit (OP)
Exactly it’s less about how many dependencies we have, and more about which failure points we’re comfortable outsourcing.
In your mind, what makes a dependency “reliable enough” to stop worrying about it?
jl2352@reddit
I don’t know why this reasonable take is so heavily downvoted.
For me the two main points are numbers of downloads (popular stuff just tends to be more polished), and is it maintained. The second you get CVE warnings for with Rust dependencies.
Further avoid something niche and unconventional. I work a lot with Rust, and so I’d prefer using Serde and SerdeJson, over one of the many faster than Serde alternatives.
Floppie7th@reddit
Because it's (A) pretty far from the point that that user has been making everywhere else in the thread, and (B) very likely AI engagement bait
Maxion@reddit
And it sounds like one of those generic salespeople that just finnished lunch with a coder and made a post on LinkedIn.
revoconner@reddit
This is not linkedin
Top3879@reddit
Bold of you to assume my own could would not have more failure points than the dependency.
pwd-ls@reddit
Many factors. There’s a lot to dependency management. Look at metrics like community adoption, current support, unresolved issues, performance, effectiveness, fit, etc.
Also you should have automated testing that will catch issues in dependencies indirectly so it’s not like dependency issues should be slipping under the radar.
In my experience the VAST majority of bugs are not caused by the dependencies.
arpan3t@reddit
There’s other ways to mitigate potential reliability issues with a dependency than bringing it in-house. That would be a last resort imo.
No_Reality_6047@reddit
They have more people to maintain it than your team
SpaceCadet87@reddit
My code unfortunately depends on a CPU. No specific CPU but that dependency is still there.
I tried, I guess I can only do so much.
DonaldStuck@reddit
I know me having to code those dependencies myself I certainly not sustainable.
zelmak@reddit
It’s all trade offs. IMO modern code tends to “rot” a lot more than older less dependency based stuff. If you write a small simple library that has no need for change it will keep working indefinitely. But if you use a dependency for what should be a small simple library then that dependency stops being updated and some of its dependencies start deprecating their old versions you might eventually be forced to update or replace it.
Glittering-Sink9930@reddit
Why?
zelmak@reddit
Let’s say you’ve got two dependencies. And you’re running node version 22. Eventually we’ll be on node version 30 and one of your dependencies will update to require version 26 as a baseline, but your other dependency will have stopped being supported and 22 is the latest version it can work on.
You have no choice but to switch one of your dependencies.
There’s an old joke that programmers like cooking because they’ll never walk into the kitchen and discover that their knife dropped support for carrots in an update six months ago
Glittering-Sink9930@reddit
That sounds stressful. I do Java where that isn't really an issue.
Plank_With_A_Nail_In@reddit
Those libraries sometimes update due to security issues some one found, your own library might have security issues but you don't know because no one looked at ever in last 10 years.
zelmak@reddit
Totally like I said it’s all trade offs. Things like auth, encryption, you’d have to shoot me before I rolled my own.
Something like timestamp formatting if my use case is simple on-prem servers that will foreseeablely only ever be in one timezone a couple functions that never age will likely do the job as opposed to a whole nest of dependencies. However if we’ve got users and servers all over the world and need different languages, formats and we’re concerned down to the leap second level no way I’d want to touch that give me a library please.
In a lot of cases “micro-libraries” that are pervasive in node js can be more of a risk than just doing it yourself. Things like left-pad and isarray are introducing more risk than they’re saving time
clickrush@reddit
I‘ve become much more wary of libraries that are updated regularly versus ones that are maintained more calmly.
peripateticman2026@reddit
Exactly.
yerfatma@reddit
Do people not remember "DLL Hell"? Everything old is new again.
Plank_With_A_Nail_In@reddit
Just ship the non OS DLL's you use in the root directory of your application. DLL hell was never a problem if actual effort was put in.
yerfatma@reddit
How is that different? If actual effort is put in now, dependency management doesn’t have to be scary. Hell, just checking for minor version bumps, using a linter or PR bot to bug you, etc. Just have to put some effort in.
Sisaroth@reddit
DLL hell was more about the GAC using a different DLL version than the dll you intended to use with the exe. It didn't have much to do with keeping depencencies up-to-date (at least that was my experience with dll hell).
RakuenPrime@reddit
Undisciplined versioning was one of the issues I remember with the GAC. It relied on properly updating versions so the strong name changed. Sometimes a vendor or internal team would say it was a new version without doing it correctly. Queue scrambling to figure out what DLLs were actually on what machines when you were trying to figure out odd behaviors.
elperroborrachotoo@reddit
For DLL hell, one supplier (by an API break under the same name) or any other client (by overwriting/uninstalling a DLL you need) could break your app on the client.
That's mostly solved (with quite some effort). Technically, it's better now: breakage would be visible in the dev environment already.
The "new" problem is one of scale and security: one of hundreds of dependencies could silently break or compromise my app, and one dep could do that to thousands of apps. We got a warning shot with
leftpad(2018 I believe), but besides on-top checking, nothing fundamental has changed. It's an infrastructure problem more than a technical one.syklemil@reddit
Yeah, it's essentially the same thing as the cycling adage of "it never gets easier, you just go faster".
Usually orgs will work on making software development faster and smoother. So we eliminate a rock in our shoes, and then start talking about the sand in our shoes, or how worn-out our shoes are, and so on.
So if we can get software supply chain security to be more of a solved problem, we'd be freed up to consider other problems. Because what else would we do? Work shorter days?
gimpwiz@reddit
It became explicit rather than assumed / not-assumed that the package manager people would forcibly take your shit over if you misbehaved, essentially, which I think surprised a lot of people who weren't really paying attention or thinking it through.
loup-vaillant@reddit
How much of those dependencies you actually use though? I would suspect only a tiny fraction of them, bits and pieces from all over the place.
You also know what’s not sustainable: you having to trust all those dependencies.
DonaldStuck@reddit
Fair question, the answer is: I'm not sure. I know for sure my software uses the dependencies I defined. Do my dependencies actually use their dependencies? I don't know.
loup-vaillant@reddit
Oh, I’m sure it does, I do trust each dependency is there for a reason. My question was not how many, but rather how much: my guess is, each dependency you take on does some things you want, and then a bunch of other things you don’t need. If you kept only the parts you need, how much code would that delete?
Of course one would have to test to know for sure. From what I have seen in my career though, we tend to use fairly heavy dependencies, then use but a sliver of their functionality. It makes economic sense, given that the more stuff a library or framework does, the more use cases it addresses, the more popular (and widely supported) it can get.
On the other hand, all that dead code is its own kind of waste.
BakaGoop@reddit
why trust a team of dedicated maintainers working on it when you can do it half as good for twice the cost
Full-Spectral@reddit
It's not quite that simple.
If I'm doing something for my own use, it doesn't necessarily have to be hyper-optimized, portable, or a fraction as flexible, because it only has to meet my needs. So something that is highly complicated and tens of thousands of lines of code with lots of conditional portability and hardware availability stuff might end up being a few hundred lines of very easily understandable code for my own needs, or even just a wrapper around an OS call if my needs are directly met by such.
wolfy-j@reddit
And you dont even have to pay them! Just being mean to open source contributors is enough to keep their engine going!
sohang-3112@reddit
😂
arpan3t@reddit
For best results show a sense of entitlement, as if you wrote the codebase yourself and they are just AI maintainers.
Unless of course, you don’t like how something is implemented, then they wrote it and it’s stupid!
wolfy-j@reddit
I’ve open this ticket two days ago, why is it still not implemented? My project is in hot water and I need you guys to fix it asap. I see that you are fully financed ($5 monthly donation) so you can’t have any excuse!
mrheosuper@reddit
And sometime that team is "a random guy in nebraska that develop his library in freetime"
wolfy-j@reddit
Which is usually synonym of a very well designed piece of software done without any crunch and with a deep love to the domain problem.
billsil@reddit
My garage code is 250k lines and has 100+ citations. It's kind of weird. It's even funnier when people ask $75B mega-corporations for assistance with it.
turtleship_2006@reddit
And sometimes it isn't such a pretty scene
recycled_ideas@reddit
Core-JS is probably the worst case scenario for a developer though.
Lots of work, lots of churn, lots of code, used in lots of places (probably as a default more than anything), not particularly fun or exciting code, but the actual value to any given customer who could actually pay is fairly minimal.
Yes, as he said, you can't just write Core-JS in a couple of lines, but you can replace the bits of it you actually need on any given project fairly easily with either other polyfills, not using new features or dropping support for older browsers. While the cost is zero people will just install something like Core-JS (or again, it'll be a default dependency of something), if it stops being free the cost to drop it is probably extremely low.
TL:DR Core-JS is shit work that makes the developer feel like the value they're providing is much higher than it is which leads to bitterness and resentment.
That's the paradox of open source, developers use free licenses because otherwise no one would use their product, corejs as a paid solution would never have gotten more than a handful of customers, but because it's free it goes everywhere and then the developer feels ripped off because the software is being used in accordance with the licensing terms they explicitly chose.
Licenses are meaningful, they are a contract with your users spelling out the terms under which they are allowed to use your software. Don't choose terms you're not happy with. If it'll piss you off if Google uses your shit for free, choose a license that doesn't allow that.
Proof-Attention-7940@reddit
Core-JS was a huge value add back when every single JS feature required you to consult MDN or CanIUse to see if it’ll work across all your customers devices for even very basic things like
Array.prototype.includes. These days, JS support is very mature- unless you’re using exotic new features like decorators (something most JS toolchains now can help you with), you don’t really need core-js anymore. But it’s continuing prevalence is a reflection of organizational apathy- why change what worked yesterday?It’s a very tough spot for a maintainer to be in, and saying “Core-JS is shit work that makes the developer feel like the value they're providing is much higher than it is” isn’t really fair to the maintainer, nor is it historically accurate. It’s only been recently that its value became minimal- and that was in part helped along by core-js!
In fact, one of the major inputs standards bodies like TC-39 use to justify standardizing features is by looking at how popular a polyfill implementing a proposal is. If there’s little adoption of that polyfill, there’s no reason to move it forward. If core-js implemented it, that was seen as a sign of just how much the proposal was desired.
recycled_ideas@reddit
To clarify, when I say shit work, I don't mean the work was done badly, I mean the work isn't fun. No one likes polyfilling.
Sure, but how much would you have paid for it? There are other polyfills, writing polyfills for specific individual features isn't particularly hard and you can so just not use the feature.
That's the problem, as a whole, Core-JS is a lot of value, but on any individual project you didn't need the whole.
roynoise@reddit
Tanstack comes to mind
tannerlinsley@reddit
👋
BakaGoop@reddit
my goat!
remy_porter@reddit
And sometimes it’s Leftpad.
Dragon_yum@reddit
That’s ridiculous. You wish my course was half as good as those libraries.
levodelellis@reddit
I can't tell if this is sarcastic. I'll assume it is because open source 99% of the time is just one guy
fragglerock@reddit
But how else will I develop a lisp?
Legitimate_Sun1783@reddit (OP)
And then we celebrate when we replace a mature library with our own buggy version… because “ownership.”
Where do you think the line is between good abstraction and over-engineering?
VictoryMotel@reddit
What's with the vague inane questions?
BakaGoop@reddit
This is most definitely a bot account looking at their history. I hate the internet now
cheezballs@reddit
Testing a new AI bot perhaps? The stuff this thing says doesn't make any sense.
giorgio324@reddit
true those dependencies exist and are maintained because many people need them
Duraz0rz@reddit
Why pay Okta or some other identity provider when I can just write and maintain one myself?!? What's the worst that can happen?
midri@reddit
Right? I know how I can totally write me own Timezone logic!
Ran4@reddit
I once wrote a bank in an obscure language, and I concur. Timezone logic is one of the worst things to handle.
(I had to fight the CTO to use an off-the-shelf web server over his own self-built...)
azswcowboy@reddit
Actually, the core logic is not that bad. You need to grasp that time is simply a count since an epoch time in some resolution (like seconds). You need functions to calculate things like first Sunday of the month. You need to understand that UTC time (excluding leap seconds) is the universal time that zones use - there’s a base offset and then a then a dst offset which is possibly zero. It’s really the i/o that kills you. To dang many ways to represent the stupid same thing. And maintaining the data the reflects the whims that are legislatures that define such things.
source: I wrote this in about 2001 https://www.boost.org/doc/libs/latest/doc/html/date_time/local_time.html#date_time.local_time.time_zone_base
SippieCup@reddit
The Japanese leap second screwed up our ad platform at a company i worked for, we worked in ad tech, because the cto rolled his own. Took like 2 days to figure out wtf was going on.
azswcowboy@reddit
Leap seconds are a whole different problem than time zones since they impact the output of the clock. Best advised to use a monatomic clock (aka TAI) for applications needing precision timing. For UTC leap seconds have the ‘labeling problem’ - either you make the leap second a repeated :59, or risk putting a :60 in the data stream and blowing up other applications. So loss of information or potential application chaos - good luck out there.
MarsupialMisanthrope@reddit
There’s a pretty wide spectrum between leftpad and time logic. A good measure of thumb is if it’s a handful of short functions that will never change write it yourself and if it’s a problem from Cthulhu’s nightmares that requires constant updates find some other sucker to do it.
DancesWithGnomes@reddit
It depends. Often the dependencies have lots of bells and whistles that I do not need, but that make them bulky with lots of sub-dependencies that I do not need either.
When libraries are no longer maintained, I have to find a replacement or dive into unknown code or have to do it myself after all.
For each dependency, there is regular work to do when I need to upgrade to a new version, because inevitably there will be a vulnerability.
The more dependencies there are, the higher the chance that there will be version conflicts, like lib A needs lib B with version 5 or higher, but lib C also needs lib B version 4 or lower.
josefx@reddit
On the other hand I have a) an ancient, internal, network stack that hasn't been touched in a decade and b) a widespread utility library with networking support. a) just exists, b) gets new CVEs every other release and company policy demands that we do not ship software with known CVEs, which makes it a nightmare to deal with, especially when a new CVE hits during a release.
johndoe2561@reddit
Depends what it is though. Do you need a package to check if a number is even or odd?
Legitimate_Sun1783@reddit (OP)
Right? The irony is we “save time” by adding more dependencies… then spend 10x that time triaging security alerts, version conflicts, and breaking changes.
Do you think the solution is fewer dependencies… or just better ones?
DynamicHunter@reddit
There is no way me or anyone on my team is spending anywhere close to 10x the time on that instead of writing dependency libraries from scratch
flukus@reddit
It really depends on the dependency and how much you're using it. Something like leftPad is trivial to write yourself. Bigger dependencies would take a lot longer to write yourself but you might only be using a fraction of it's features anyway.
mattjouff@reddit
It’s true from an economic stand point. But the consequence is software that becomes more and more bloated and runs like shit. And you may say: well we have infinite resources now anyways. But once you start layering these libraries, each trying to accommodate wide use cases and therefore poorly optimized for the task at hand, you end up with shit.
protostar71@reddit
Do you ever comment or post without asking a question to drive further engagement?
The_Shryk@reddit
The dude is either AI or is so AI pilled he is AI.
It’s AI either way.
protostar71@reddit
Oh 100%
ShinyPiplup@reddit
Damn... I'm self conscious now. I talk like that guy. And I thought I was honing a very inoffensive and non-confrontational way of speaking the past decade. Reading these comments, this was apparently the wrong move.
protostar71@reddit
Your comments don't read the same. What flagged it for me was specifically that they kept asking tangent questions to drive more engagement. It's in all of their comments, except for the first one they commented which was to increase the comment count from zero, again to get more engagement.
nyctrainsplant@reddit
It reads more like a human engagement farming than a bot.
gimpwiz@reddit
You're disagreeing with the person you said "Right?" to by ignoring everything they wrote.
OpticalDelusion@reddit
If you spend 10x your time doing that the answer is probably both. Reminds me of all the joke libraries that wrap inane things like addition.
One_Being7941@reddit
Yeah like left() right() and mid().
levodelellis@reddit
I have stories about that... There's no beta of the product out yet so I don't think anyone wants to hear them
Olli_bear@reddit
Exactly. Nowadays there's a dependency for everything, so why would we code something if it's just a matter of importing something already done. This allows me to create more robust apps.
fabis@reddit
> most projects spend more effort patching dependencies than writing application logic
Not even close to being the case from my experience, even as a JavaScript dev. Of course if you don't carefully vet the deps you're adding you may have to do more patching & fixing, but generally it takes a single-digit percentage of my my time spent doing development.
DonaldStuck@reddit
💯 this is virtually a non-existent activity for me and I do React
Glittering-Sink9930@reddit
I'm amazed this is a thing at all in Javascript. I have never heard of anyone doing this.
nyctrainsplant@reddit
Sounds like you're missing a lot of react dependency vulnerabilities. They come out all the time.
zazabar@reddit
Probably depends on the context. I do work with the US Department of Defense, and our applications and containers undergo daily scans with tools like trivy and fortify. There is usually a number of JS packages for our react apps that have to be updated every month, especially since in this world you have to use version pinning for basically everything.
ProtoJazz@reddit
I worked at a place that decided we wanted to keep all our shit up to date from now on, and stop letting teams get behind
So we formed a cross team group that took a member from each team. Every month of so the cross team group would meet and organize things like that. What the minimum dep versions were, hell even what deps we use as a company.
Wed also do stuff like communication on standards and stuff. Usually small shit, but stuff that really makes things feel like one unit. Like how to display alerts and shit.
The leads initially complained, said they didn't like these requests taking priority over existing work. However since this was an initiative from the very top of the org, they were essentially told either you let your team member attend these meetings and do these tasks with priority, or we'll make you do them.
eflat123@reddit
We learned the hard way, a couple times, to keep versions and dependencies up to date even when there's no active feature work planned. We'll go no more than 6 months, usually less. Scheduled work.
roynoise@reddit
That's truly amazing.
roynoise@reddit
Fluent Assertions & Moq unfortunately come to mind.
Humprdink@reddit
woof
Toobwoozl@reddit
The only time I've spent more time fucking with dependencies than actually writing code was when I dabbled with micropython. I get stressed just thinking about it!
LouvalSoftware@reddit
yeah this is stupid as fuck, maybe SOME companies in SOME cases will maintain their own fork of some critical mega dependency they need bespoke functionality out of... but like lmfao if I have to go into a dependency to make it work then im looking for a different one to depend on. its in the name
Revolutionary_Dog_63@reddit
There isn't always a different one that works. I've worked with a few obscure protocols that operate over serial that have no good open source solutions in Python, so I've had to roll my own. Mine have proven to be more feature complete and stable, plus they're easy to change because they're mine.
AiexReddit@reddit
We have a few forked dependencies, and I think each one of them without exception is like the thinnest possible wrapper or edit to basically implement only the thinnest critical additional piece or modification we need to make it work, and nothing more.
This is only after trying to submit PRs to the original and working with the maintainers to find a reasonable path to implementation, seeking out alternative dependencies, and then when forking becomes the last option, still pulling upstream non-stop keeping a constant watch on our fork for anyone who decides they suddenly want to get creative and add any new code that could complicate the path toward just getting back on the upstream in the future.
Maintaining forks sucks.
gimpwiz@reddit
Even at the most annoying I've had to deal with, I wasn't spending more than 10% of my time chasing down bugs in my libraries versus time I spent writing code. I am pretty sure for most teams that's <1%.
BrickedMouse@reddit
I work om a 7yo code base and never work on dependencies, UNTIL, we started updating Spark, JVM and Python at the same time. It took a month with multiple people
koreth@reddit
Yeah, this is a weird take. In an average week I spend maybe 15 minutes thinking about dependency updates. Usually my dependency-update work consists of going through the automated pull requests from Renovate, making sure they didn't break any tests, and reading the release notes to see if there are changes we need to care about. Sometimes I look over the code changes too.
I have Renovate configured for weekly updates except for urgent security patches, so for me, dependency updates are usually just what I do first thing every Monday, then don't think about until the following Monday.
Original-Ant8884@reddit
Idiotic. My hello world program is 99.99% dependancies. Is it sustainable?
AlaskanDruid@reddit
Of course work smarter, not harder is sustainable. It’s literally an important life lesson to learn.
wildjokers@reddit
It wouldn't be maintainable for a company to write everything from scratch. Write our own web server? Write our own JSON parser? Write our own HTTP request parser? What would this give us?
uCodeSherpa@reddit
Always the slippery slope with this sub. Every single comment too.
Obviously, the case here isn’t that you would or should write your own web server. But that you probably should be more careful about left-pad as a dependency, or bringing in entire data parsing libraries to format a date.
FabulousJunket8084@reddit
The fix isn’t rewriting servers, it’s ruthlessly curbing tiny deps and setting guardrails.
Rules that worked for us: no deps under \~200 LOC, cap runtime transitive depth at 2, block packages with bus factor <2, pin with lockfiles, run osv-scanner and weekly updates, vendor critical utils, and enforce size budgets in CI.
Day to day I use FastAPI and Prisma, and for quick REST over legacy DBs, DreamFactory handled auth and rate limits without a pile of middleware.
Guardrails beat rewriting web servers.
zerries@reddit
You've got to ship your own browser too.
-Knul-@reddit
Why not write the OS yourself?
wildjokers@reddit
You aren't doing it right unless you find your own silicone deposit, start a mining to company, mine it, and then use it to manufacture your own CPUs with a proprietary architecture.
UnoStufato@reddit
Imagine using pre-existing Silicone. You're just moving the dependency to a supernova billions of years ago.
REAL programmers create their own Silicone atoms with particle accelerators.
Agitates@reddit
Particle accelerators!? What kind of dependencies do those have?
Ameisen@reddit
How are you finding silicon without first creating a universe, having it undergo recombination, and then having heavier elements formed by stellar interactions?
peripateticman2026@reddit
Amateur. Procreate your own engineers from your loins first.
wvenable@reddit
One might not write their own OS but they might ship one in a container.
nyctrainsplant@reddit
In the end this argument conflates smart dependency choices (huge, complicated, core utilities) versus poor ones (small dependencies, with lots of bugs, that can be replaced or forked pretty trivially) which are much, much more common, especially at the level most CRUD developers are making decisions at.
key_lime_pie@reddit
It can be maintainable if the alternative is worse. In the medical device space, everything that you didn't write yourself is considered Software Of Unknown Provenance (SOUP) and has to be treated differently, to the point where many places make a concerted effort to avoid using it. The last place I worked at, the only software that they didn't write themselves were the microcontroller drivers.
ayayahri@reddit
Most products would never ship and what little gets through would be a trash heap of bugs and technical debt.
Even in "normal" practice, it is DEEPLY frustrating to work with people who seem to have no awareness of the outside world and apparently prefer to let their tech stacks fossilize/rot.
Fearfultick0@reddit
Most dependencies are open source, so they can be modified and “brought in house” if needed. Versioning can also be frozen to keep things stable. It does put more overhead to keep everything working but less overhead than writing everything from scratch.
DancesWithGnomes@reddit
"Everything" being the key here. There will be no reasonable application without any dependencies.
However, throwing several MBs of dependencies on a problem just to avoid an hour of coding, that is the other extreme that is not sustainable.
Fearfultick0@reddit
Obviously. Every team has to decide what trade offs they need to make
flit777@reddit
Problem are security vulnerabilities. Most annoying thing if there is a problem in a transitive dependency etc.
lord_braleigh@reddit
But any code can have a security vulnerability, whether you wrote it yourself or not. And the most common security vulns nowadays are supply chain attacks which come from blindly updating libraries to new code that you didn't read.
flit777@reddit
No, supply chain attacks are not the most common ones. The most common ones are outdated dependencies with known vulnerabilities.
And the nice thing for known vulns is, that there might be an available exploit which any script kiddy can use.
lord_braleigh@reddit
Code doesn't rust. By all means, update dependencies if you get CVE warnings.
But if you use dependencies that are very well-tested and fuzzed for security vulnerabilities, and if you think seriously and critically about your application's overall security instead of blindly treating every CVE warning in a dependency as a P0 bug, then you can afford to wait a few days before you update.
For example, using an "outdated" version of SQLite is fine. SQLite is the best-tested software in the world.
Yes, "outdated" SQLite builds do have published CVEs, but the CVEs assume the attacker can send arbitrary SQL to SQLite. And if they can do that, then you have already lost.
flit777@reddit
Problem is that you have a lot of dependencies you can not critically think about each CVE. (imagine any random node project which has 100s of dependencies for stuff like rimraf and leftpad)
Great that sqlite has these tests, but there is no 100% certainty that there will be never any vulnerabilities. Curl also has a lot of tests and does great things, but still there are vulns and you need to update if certain vulns are detected. So you should be able to update your system if there is an attack vector and risk. So better use a package manager where it is easier to update than just copy the source code into your source tree and you don't even know what version you are actually using.
Also take Linux. If you don't update, you will have an insecure system. ("If you are not using the latest a stable / longterm kernel, your system is insecure" gregkh)
paraffin@reddit
But with OSS you get CVE’s which need to be addressed for compliance reasons.
gjosifov@reddit
No, the problem isn't security vulnerabilities
The problem is managers thinking the software is finished and they don't want to spend money on updates, just "features" - because they sold the idea to customers that the features have values, especially at mature products
There is a small list of software projects that can't be updated, everything else can be upgraded every 2-3 years and the more you update the less painful it is
Security updates are annoying, but unmaintainable software is great business model for hackers groups, so much so that the market of hacked software is bigger then illegal drug market
loup-vaillant@reddit
To be honest, a big part of the problem is our inability to actually finish our software¹. There should be a point beyond which good enough is good enough, even in that implies very high quality.
[1] We first need to let go of the notion that software can never be finished. It can, at least asymptotically.
TexMexxx@reddit
I have to update our project everytime we get a dependency vulenrability over 7. 90% of the time these are transitive dependencies and the direct dependecy has no upgradeable version... It's a pain in the ass
Legitimate_Sun1783@reddit (OP)
Totally having the source is a safety net a lot of industries don’t get.
But I’m curious: how often do teams actually fork + maintain a dependency themselves vs. just hoping the upstream fixes things?In theory, we could own more but do we really have the bandwidth?
cheezballs@reddit
Why would you fork and maintain instead of submitting a PR to the repo?
Maxion@reddit
I've had to do it. Needed a change that the maintainer(s) didn't want to merge in one case, the second case was the repo was already abandoned and they had moved on to V2. We could not move to V2.
ProtoJazz@reddit
I've done it, mostly with abandoned shit that just needs a couple of small changes to work. Usually in the case of there not being an alternative package
So I can either write my own, or fork it.
Or another case is you do open the PR, but you want to use those changes immediately
cheezballs@reddit
Oh, yea for sure abandoned stuff definitely. No choice then.
Fearfultick0@reddit
The beauty is that if it works, you can just use the dependencies as they are. If you need something custom, you can make modifications. If they are abandoned by the community, you have the code and can still use it or adjust it.
SpaceMonkeyAttack@reddit
Not often. But I've done it before. Usually just to fix one thing, and then switch back to the mainline version once it's fixed upstream.
ProtoJazz@reddit
once/if
diverge123@reddit
we vendor parts of some crucial packages, but also try make upstream contributions wherever possible
Nilzor@reddit
What do you mean with "patching dependencies"? Like.. Upgrading them? Or actually bugfixing someone else's code? If it's the first, the solution is simple : Don't upgrade. If version 1 of the dependency gets the job done, you don't need to be on version 2
p-x-i@reddit
I recently asked Claude AI to refactor my medium complexity react/MUI/SPA to use no dependencies other than a modern browser. Mind blown. Looks and works much better.
emperor000@reddit
In other words it just copied a bunch of code from existing libraries, likely without giving any accreditation...?
Even if it didn't do that, sorry, this is not any kind of flex.
NYPuppy@reddit
I read that person's post as sarcasm but if it isn't then..that's concerning.
p-x-i@reddit
no - it rewrote my code to remove all external libraries and re-implemented it with straight es6 which runs fine in any modern browser.
MaDpYrO@reddit
Just means that we are using more open source projects, instead of 100% of our code being dictated by corporations
codethulu@reddit
you think open source isnt dictated by corporations?? lmao
digitizedeagle@reddit
Better still, let's return to assembly language in our quest to avoid all layers of abstraction. You could retire to the mountains to -eventually - do in 10 years what you now can do in 3 months.
codethulu@reddit
asm isnt that much more costly to write. it's more expensive, but not 40x more expensive.
Thin-Yard471@reddit
I understand how you feel. That's a great question, and one that pops up often in our industry.
When I was younger, like many others, dependency-heavy approaches felt new and risky. But over the years, I've seen firsthand how working with common libraries evolved into a full-fledged industry trend. My early projects were much more "build everything" type of work, but I remember seeing teams around 2015-2016 start to lean heavily into dependency ecosystems like Node.js and its npm packages.
My current thoughts are about finding balance. I've learned that "build vs depend" isn't the right framing—it's more about evaluating trade-offs:
JoesRealAccount@reddit
This is stupid. If you don't use dependencies you gotta write it yourself. What a stupid article
Dangerous-Pride8008@reddit
50% dependencies, 43% vibe coded slop, 15% concentrated power of will.
cib2018@reddit
How do you even measure that?
shizzy0@reddit
The dream was code reuse. The horror now is code reuse. I don’t get it.
sheep1e@reddit
It’s only a horror for people who don’t really understand what they’re doing.
nyctrainsplant@reddit
Which is most teams, as this and many other reports indicate.
sheep1e@reddit
Well, if you take a team that's having problem with using 3rd party dependencies, you're certainly not going to improve matters by having them implement everything themselves.
The other "internal report" that we don't have access to (just like this one) is the one from the alternate timeline where this team did that. I can guarantee that the results would be a lot worse.
Marble_Wraith@reddit
Clearly it's talking about Javascript.
Golang has no such problems 😂
silon@reddit
The problem are only dependencies that cause churn... IMO, anything that goes much beyond 3.1 version should be considered suspect (be split up).
emperor000@reddit
What do you mean by 3.1 version?
LegitimateBoy6042@reddit
This is very true. Even I spend a ton of time fixing these dependencies issues than actually working on development.
clichekiller@reddit
My concern regarding dependencies, especially those developed by small teams or single developers is building my application around something that could go away, or worse, be acquired by bad actors, who may use the dependencies popularity to spread malware. Then you have that one package that broke a huge swath of the internet when it was taken down by its author.
Very few people take the time to inspect the dependencies’s code, or understand how they work, myself included. So you are trusting the security of your application to others, and assuming professionalism, and good intentions.
Literature-Just@reddit
I don't like dependencies because they take up too much space. You don't like dependencies because they do too much for you. We're not the same.
arhimedosin@reddit
But
the article refers to JS ecosystem only. It is not related to "software" in general, or "codebase"
Yes, it is a well known fact that JS is a nightmare, they invented the term " dependency hell"
So what is new here ?
Tall-Introduction414@reddit
We used to use it to refer to RPMs in RedHat, and Windows DLLs, back when JS was little more than a novelty.
syklemil@reddit
Isn't the Windows term "DLL hell"?
But yeah, it's a pretty old term at this point, way older than NPM. It also used to involve the frustration of needing two incompatible dependencies, or dependencies that aren't available on your OS version.
Probably "dependency hell" was what prevented people from ramping up how many dependencies they had. Once something is easy and painless, we tend to do it more.
Tall-Introduction414@reddit
Yeah, I think you're right about DLL Hell.
The reason RPM was such a PITA, was because it had dependency checking, but not automatic fetching of dependencies. That came a bit later with Debian and Apt.
So you would try to install an RPM, and it would depend on some other RPM. You would download that RPM, at dial-up speeds, and find out that had more dependencies. If you didn't have a local CD of the entire Redhat RPM archive, you were toast.
Later on Redhat got dnf and similar dependency fetchers to solve the problem.
syklemil@reddit
Yeah, I think Kids These Days™ don't have a clue what a PITA package management was in the day. Bonus horror if you found out you needed/wanted something that wasn't in the repository and you had to figure out what
./configurewas complaining about. Or you did find an RPM, but it was from another distro, and maybe it would work (though that was hopefully mostly something stupid teenagers (like me) did).At that point in time, any additional dependency was a potential nightmare just to get to work, let alone update. So of course we wanted as few as possible of them.
(If we wound up with some sort of cryptolocker through one of those dependencies I think we'd be too impressed to be mad.)
emperor000@reddit
What alternative are you suggesting? That the functionality of all of those dependencies, or some reasonable amount, be rewritten each time it is needed?
Plank_With_A_Nail_In@reddit
Most of that wouldn't have been viable without those dependencies.
alonjit@reddit
Not having those dependencies is definitely not sustainable.
Tween_the_hedges@reddit
Always has been. And if you're park clutching about it is like to talk to you about your runtime, compiler, os, standard library, target environment, and hardware. If you want to avoid being dependent on others better start prospecting for silicon
reveil@reddit
Most languages have a decent standard library that cover the majority of required things for most projects. The rest you install and maintain via packages keeping in mind that each dependency is both a benefit and a cost. Then there is the absolute insanity of JavaScript and npm and leftpad type packages in the thousands for most projects.
Tall-Introduction414@reddit
Exactly. Javascript's culture is all dependencies all the time, because its standard library is such dogshit. That's not really a good thing.
AuroraFireflash@reddit
And that's before you consider that the default package manager for JS allows packages to execute scripts within the developer's context when you run "npm install".
It's not opt-in, you have to specifically tell it "don't do that".
tenkitron@reddit
Beat me to it. At my job we use clojure and because of its thoughtfully designed nature and completeness as a general purpose language for getting things done, we’ve found we rarely have to reach out for external dependencies for most things that we do that involve it as a language.
frymaster@reddit
I don't know if this means "writing patches for dependencies" or "updating dependencies" or "adjusting their code due to changes caused by updating dependencies" but if the first - It's possible this is the case for developers who are themselves writing libraries, but I don't think it's the case for teams who are mostly just consumers of dependencies
Tax_Odd@reddit
Most low skill devs have no idea how to structure code. There are coders and there are programmers.
If you have a good design, its usually harder to use libraries but you don't need to.
Instead we have code that looks like a patchwork quilt.
Tax_Odd@reddit
The average CPU is 10x more efficient than it was 10 years ago, yet somehow that 10x speed improvement seems to have gone backwards in consumer applications.
No you don't need a new library to parse a string.
syklemil@reddit
The text before the CVE graph is worth being repeated IMO:
More CVEs isn't bad in itself, and getting them fixed in a dependency means that lots of locations get the fix. If they'd copied the vulnerable code rather than add the dependency, they'd still have the vulnerability, but not be alerted. If they'd written it themselves and never published the code, it's not a given they'd discover the vulnerability before they're exploited.
Dependencies come in a range of quality, but so does in-house code. Dependencies may be abandoned, but so can in-house code; we just call it "technical debt" or "legacy" rather than "abandoned" when it's in-house, even when it hasn't been touched for years, and there's nobody still around who has ever worked on it.
yksvaan@reddit
Well the problem is that people don't abstract away dependencies so any changes to them or refactoring bleeds into the rest of the codebase. The core logic, data structures etc. needs to be controlled and acts as a glue to use dependencies while being in control.
nightwood@reddit
It would be better if it was 90% dependencies, but it's really hard to write, document and design good reusable software
kevintroko@reddit
I spent the whole last week upgrading deprecated libraries at work
hobbestherat@reddit
Imports in software should be tariffed more than they are. (Unless for a throwaway prototype or so)
DoomDom911@reddit
If Someone is Interested im Creating a Project with me dm me
rrzibot@reddit
No
KnownDairyAcolyte@reddit
no
MorrisonLevi@reddit
Most projects "stand on the shoulders of giants" and in software, that's mostly dependencies, either direct or through the OS.
Honestly, I would have figured it to be higher.
Clitaurius@reddit
Exactly. This is like semiconductor engineers fearing x86 as a dependency. "We can't import math.binary!"
Ai--Ya@reddit
“The proof of a theorem is 50% citations — is this sustainable?”
LeifCarrotson@reddit
It is higher, the article claims 70-90%. Don't know why the title says 50%, that appears nowhere in the article.
claypeterson@reddit
As a game developer I feel bad for you. Writing code is fun. I guess getting it done is the point but still
krkrkrneki@reddit
Claim "codebase is now 50% dependencies" makes no sense.
Also if you tried to replace dependencies with your own solution, you'd spend an order of magnitude more time.
ProjectPhysX@reddit
No, it is not sustainable. Dependencies suck. Dependecies are unreliable and break, and then they also break your code.
In my pojects, maolny FluidX3D, I go zero dependency. When I need something that is available as dependency, I write it myself instead. Takes more time initially but I know that my code works, and I only implement what is needed and not the remaining 1M lines of library. It pays out later: my code then works on every operating system, every computer from the last 2 decades. And as an added benefit, it compiles in 5 seconds.
septum-funk@reddit
this thread is giving me the idea that people overestimate and underestimate how many dependencies certain projects need. what percentage of all programming projects actually need an identity provider at all? or is that specifically the field you work in that justifies heavy dependencies? and conversely what percentage of projects need to cut back on dependencies? or do you just work in embedded? "the average codebase" feels like a very vague title.
Amazing-Mirror-3076@reddit
50% is not even close, try 99% +
Database, webserver, proxy dicker..., not to mention the actual os.
The job of developers it to build reliable systems. Third party code is almost always going to be better than your own.
mask_of_loki@reddit
Well, that depends
fasti-au@reddit
Actually it’s 100% a we don’t actually write in assembly but hey. Let’s figure out what’s a dependency.
Ignore copyright and license etc as it’s no longer relevant. All those sco Unix court cases don’t work with AI, the pile and Suno. The ai does it not you so hit a button read an output. Not reverse engineering it’s a guess.
If you download the code it’s not a dependency it’s your code someone else wrote now.
morglod@reddit
Funny how they talk about safety and then this openssf scorecard has a lot of dependencies and needs your github auth token to run... on public repo...
brentragertech@reddit
Yep. Next!
dra_cula@reddit
It's not only sustainable, it's desirable in the sense that it embodies the concept of OO programming.
Pharisaeus@reddit
100% is some sort of dependency. Compiler? Standard libraries? You'd have to writing raw machine code to "avoid dependencies". And yes, it's sustainable - I'd rather use a well-designed and maintained library over writing some questionable code that needs to be maintained later. Sure, you shouldn't go crazy with importing left-pad or is-even, but if you're implementing your own collections or cache or database then in 99% of cases you're making a mistake.
WarEagleGo@reddit
I agree. Just think of the similar HW system (such as a automobile), even if I make my own steel, glass, and rubber, by mass that means something like 70% of the mass I am dependent upon outside vendors
Bakoro@reddit
It's more like, how can you afford to not have a bunch of dependencies?
If you're programming on bare metal, then maybe you roll your own everything with C.
More often than not, you are depending on the operating system, including the GUI, a networking stack.
You really don't want to roll your own database or crypto.
Most people don't want to make their own game engine.
If 50% of time is spent patching dependencies, how could you be sure that 100% of your time wouldn't be spent maintaining your own implementations, and you stop being able to write any business logic?
bwainfweeze@reddit
I think it argues for more aggressive incorporation of Wisdom of the Crowds into either standard libraries, or creation of curated collections.
There's nothing stopping you from deprecating a module in a library the same way such a module might be end of lifed when living in isolation. And if the module dies due to evolution of the language making it awkward rather than obsolete, then there's more incentive to prevent a gap from forming.
lacronicus@reddit
it's not dependency hell, it's a modular, highly distributed, democratic standard library.
ProteanLabsJohn@reddit
Yup, and did you know that most people don't update their dependencies more than once per year on average? scary shit
DragonSlayerC@reddit
The codebases I work on (golang based) are over 90% dependencies by lines. It's a house of cards. To be fair, this has caused nightmares when there's a mismatch in dependency requirements already.
_commenter@reddit
It’s not sustainable we’ve been seeing more and more supply chain attacks where attackers poison dependencies. It’s really prevalent in npm right now now, but the same exploits have happened in Java ecosystem, Ruby gems etc.
I really try to minimize the dependencies I bring in now.
Marcuss2@reddit
The alternative - handrolling things which dependencies deliver is even worse.
lotgd-archivist@reddit
If you wish to make a website from scratch, you must first invent the browser.
dskippy@reddit
I think the best code bases are a large percentage dependency. The more the better. That's code maintained by other people and the effort aggregated across the entire community. It's the greatest strength of software development culture that is so democratized and free.
PurpleYoshiEgg@reddit
Where is that 50% figure? I want to know more about that.
ZirePhiinix@reddit
If you wrote something that "had no dependency", it doesn't actually mean what you think it means.
Verdeckter@reddit
Are you proposing keeping dependencies up to date is less sustainable than every team writing and maintaining all of that logic themselves instead?
Beautiful_Watch_7215@reddit
No dependencies and only one function. Keep it clean.
LineRepulsive@reddit
Coming from several companies where I worked with dotnet, including some apps for big corporations, and recently working in a startup with typescript I was shocked how people just npm install any shit that is convenient
Do you guys really don't care that you bring into your codebase some code that you never saw, and even allow in the package.json to upgrade the version automatically? I mean I did that for personal projects but it's beyond me that it's current practice for many production apps.
And yes I know we have nuget packages in dotnet which is the same but in reality a few of them a really used
Fritzed@reddit
Really, having dependencies isn't too big of a problem because you know what you called in. Where it gets really messy is trying to know anything about your dependencies dependencies.
HonestyReverberates@reddit
Most projects do not spend more effort patching dependencies.. wtf?
kintar1900@reddit
The average codebase in what ecosystem? I know the Go code I write at work is nowhere NEAR 50% dependencies. Maybe not even 10%. (I assume we aren't counting the standard library.)
The C# code we write/maintain has a larger dependency tree, maybe 20-25% for things that deal with PDFs and the like.
Node code? Yeah, we're talking 800MB of deps and 20k LoC. It's a fucking nightmare.
bishopExportMine@reddit
Damn, 100% of the code I've written has been dependent on either x86 or ARM assembly. You guys gotta tell me what I'm doing wrong.
Legitimate_Sun1783@reddit (OP)
Funny thing is: dependency count used to reflect complexity…
Now it reflects how quickly we wanted to ship.
cheezballs@reddit
How old are you? We've been using dependencies and external libraries forever now. It's not a new thing. Do you really want to write everything in assembly?
cdb_11@reddit
https://en.wikipedia.org/wiki/False_dilemma
Floppie7th@reddit
And run it in ring 0, since an OS kernel is a dependency
corysama@reddit
Alan Kay on
lordlod@reddit
Oh dear, another sales pitch for a CVE scanning tool.
I believe 50% also wildly underestimates the dependencies quantity.
libc, which almost every Linux program uses as a dependency is roughly half a million lines of code. The MSVCRT.DLL is not small either.
Is your program half a million lines of code? Congratulations your code base is now at 50% dependencies, assuming you use no other libraries. Most code bases are of course significantly smaller.
Have you ever had to debug and patch a libc fault? Yeah, me neither.
BlueGoliath@reddit
You're telling me React and Spring Boot Per Clinic developers use other people's code instead of doing it themselves? Wild.
Valuable_Skill_8638@reddit
I aquired a project a year ago from a startup that is a fragile pos because its linked to half a dozen api providers. Thankfully its going away so nobody else will ever have to deal with it.
-grok@reddit
After 10 years of LLMs headline reads:
rohstroyer@reddit
Good luck getting rid of every dependency in your project. You'll have to create your own hardware and instruction set, then your own language, a compiler for it, an OS to run on the machine, a way to interface with the hardware while keeping your API secure, then write something that will provide a framework for your app to run on the given hardware. And don't even get me started on how much you'll need to do if you want to be able to use networking capabilities. That's before you even think about having functional dependencies like maths, debugging, memory management etc. libraries.
Or you know, pick your battles. Suck it up and accept that it's absolutely unreasonable to expect a project to not have any dependencies. Focus on writing good code for your actual use case, instead of trying to reinvent a production-ready battle-tested wheel.
PM_ME_YOUR_SUBARU@reddit
> The average codebase is now 50% dependencies
Did anyone read the linked article? This stat is mentioned nowhere in it. I read this title and thought there's no way the actual number is that low. The actual stat in the article:
> Similarly, a 2022 Linux Foundation study found that 70-90% of any given software code base is made up of open source components.
I'm absolutely not surprised by that number and nobody should see that percentage as a problem. If I created a web app with React+FastAPI I would expect those two dependencies alone to dwarf my codebase by LOC. Same thing if I'm doing ML, whatever framework I'm using would obviously be so much larger than the code I write using it.
irqlnotdispatchlevel@reddit
Did they explain how they arrived at that number?
A naive approach might be to sum the number of lines of code. So let's say that I have written 5000 lines of code and pulled in another library that is also 5000 lines. This would be a 50/50 split.
But this breaks pretty fast. Some libraries are huge, but you may end up using only a tiny part of them. This is harder (impossible?) to actually measure.
IsleOfOne@reddit
The AI model that wrote the post hallucinated
IsleOfOne@reddit
It's a bot / AI submission.
Grmplstylzchen@reddit
As a management consultant I would say
„It depends.“
throwaway490215@reddit
Wait till I tell you about the thing called an OS.
There is a problem there about the quality of our abstractions, but the metric as stated in your title is completely meaningless.
Chorus23@reddit
Software reuse gone mad. It's always a judgement call but wherever possible write your own code, rather than relying on third-parties.
cheezballs@reddit
Oh, brother. 🙄
Chorus23@reddit
Why? Don't just roll your eyes.
sheep1e@reddit
It’s because the actual situation is almost always the exact opposite.
Unless you’re talking about something really trivial, it’s an enormous amount of work to “write your own code” to do something which already exists as a well-implemented and well maintained dependency. So much work that in most cases, it’s simply impractical, and the outcome will usually be worse than if you just used a dependency.
Of course, you should select dependencies with care, and some people don’t do that, which can lead to problems. But other than that, this is mostly a non-issue.
turtlebait2@reddit
Why? The purpose of software is to solve a problem, and if you have to re-engineer all the already solved problems then you'll never get to the point where you're actually delivering any value to anyone.
Chorus23@reddit
Read the OP's comment.
aykcak@reddit
Depends on the codebase
If it is a JS project with NPM, the dependencies are like 98% of your code
jrochkind@reddit
I have come to the conclusion that there is in fact no sustainable way to produce the quantity of software our society now depends on (and wants to increase!) without it being super crappy.
Our society literally couldn't afford it, like we couldn't afford that slice of the GDP.
This is not accounting for AI though, if AI is somehow able to produce mountains of software for us, that could be different. (that is not crappy? Over the long run? I don't think we have that yet, but maybe we will eventually).
sheep1e@reddit
That sounds like more of a problem with your organization. I doubt this is the common case. And if by “patching dependencies” you mean actually modifying their source, that’s definitely not the common case. Maybe with some legacy languages?
Adorable_Tip_6323@reddit
Do we want progress or stagnation?
Progress means learning from others, both their wins and losses. In programming those are dependencies.
What we need is the % dependencies to actually rise, not fall. General logic should be shared, and enterprise specific (whether that is Facebook's algorithm, or your own personal e-light switch) logic should be custom. As more of the enterprise specific logic becomes unifiable, that should shrink the local workload, and we should see more reliance on dependencies.
And I'm pretty sure I just wrote the entire behind Python being popular.
One_Being7941@reddit
Nope. But we're in the end times anyway.
TemperOfficial@reddit
Said this years ago and people shit all over you for bringing it up. Eventually you get old enough that you just see the same cycles of mistake and group think over and over and over
levodelellis@reddit
Only 50%?
The current project I'm on (an IDE) only has 2 dependencies. SDL and freetype. Everything else (git, LSP, DAP, diff's, etc) are used through stdio (or sockets) so it can't crash the main program. Life is easier when you can get away with little to no dependencies.
Humprdink@reddit
It's a pain to keep deps up to date for sure, but it's a small fraction of the work from what I've seen at my jobs and side projects. Also I've found AI (Claude Code especially) happens to be really good at performing the updates and migrations for you. I updated a large codebase after a long time of no updates, and Claude handled migrating things like Firebase APIs all for me. Of course you have to test/verify that it did it correctly.
hackingdreams@reddit
Well you see, if you pawn off all your work onto someone else who's doing the work for free, it saves the company a lot of money.
Now, who's going to be responsible for the pieces when they break? Who's to say, but it ain't us. No sir.
lgastako@reddit
Definitely not sustainable. It's way too low. There's no way there needs to be 50% new code in most applications.
iamanerdybastard@reddit
My gut says that’s because so many projects are build with Node and the dependencies there are fucking toxic hell.
FeetPicsNull@reddit
Just wait until you see how much source code there is in the platform stack required to run the code
White_C4@reddit
Do projects really spend more time patching dependencies than writing application? I'd understand if we're talking about major updates, but that's the price to pay for shifting to newer system. And those rarely happen as most companies see sticking to the legacy version as safe and cost effective.
RumbuncTheRadiant@reddit
Next, very very embarrassing question... what proportion of the budget is spent on contributing to the maintenance of those shared dependencies.....
optimal_random@reddit
Code reusability is not sustainable?
Do you know the expression: "That was not built here" in Teams? Where there's a systematic feeling of building everything from scratch, and when the bugs pile-up, and they always do, these folks spiraldown in all kinds of rationalizations.
That's not sustainable either.
g_bleezy@reddit
Keep using dependencies please.
ByronScottJones@reddit
OP, what exactly would you propose as an alternative? Don't use any dependencies and write all of the code yourself from scratch? Please explain how that would be more sustainable than updating the version numbers of your external dependencies when needed.
thats_so_bro@reddit
The only time to not use a dependency is when you think it won't be maintained. Existing work will always be faster than coding it yourself. There are so many systems and programs on a PC that are maintained externally that you depend on everyday. It's modern life in a nutshell, and probably why the unix philosophy works so well. If you're really bothered, go contribute to the project yourself.
tmetler@reddit
I use next.js as a static site builder for personal websites. Those code bases are probably 99% dependencies. They are also built and deployed on platforms that are 100% external. I don't think I should be writing my own framework or server code when there are battle hardened options available.
Haphazardly adding dependencies is dangerous and a problem, but, this is not the right metric to measure it.
PapaOscar90@reddit
Supply chain attacks will be commonplace.
harmonicgenerator@reddit
How was the report generated? Am curious about methodology
cheezballs@reddit
It has to be. There's no way around it unless you want to re-invent the wheel every single project. There are ways to mitigate dependency attacks and things. Just have to be as good as you can about it.
amejin@reddit
Not invented here is a problem when your core functionality relies on dependencies and you can't edit them yourself and the maintainers don't care about your specific use case.
Perfect-Campaign9551@reddit
I don't think it is. And then a bunch of those dependencies get CVE's against them and not you gotta maintain it all anyway
Legitimate_Sun1783@reddit (OP)
100%. And the wild part is: a tiny sub-dependency buried five layers deep can force a full redeploy.
Do you think the answer is stricter dependency vetting… or just accepting the maintenance tax forever?
no_awning_no_mining@reddit
I think we're seeing more critical CVEs and the stakes higher earlier after discovery. So frequent updates are not only good news. It also raises the stakes on "security by obscurity" that "roll your own" inevitably is. Think of every update as solving a perfectly manageable and standard microdisaster that keeps you from having to deal with a megadisaster that is everything but.
darth_voidptr@reddit
The part that ends up being more painful is doing unnatural things to fit a dependency API or framework, and what happens when they dependency stops being supported (or in the case of Intel Hyperscan - what happens with the owner doesn't want his library to support rival CPUs and you have to use a Vectorscan instead). Dependencies not being supported does tend to happen when the authors need to eat and pay rent, and aren't making money on their side project. Or have to go work for companies who will not allow them to contribute to the projects they own, which is perhaps the most awful abuse from corporate america who is clearly profiting immensely from this.
The rest is just testing and patching, which you'd have to do anyway regardless of the provenance of the library. The value of the dependencies is that, if you choose wisely, the library has a lot of users and is already getting a lot of testing.
_tessarion@reddit
Huh? The whole point is abstraction of low level stuff (eg sensor drivers) to work on the stuff you want (eg a fan speed controller app)
TeaSerenity@reddit
Dependencies aren't a problem if you are thoughtful on when to use them directly and when to build an abstraction layer around them so you aren't married to the dependency. Sadly these often aren't easy decisions because you have to see the future on what is likely to change in the future.
It's unrealistic to build everything from scratch. It's foolish to depend on code that changes for reasons you don't control directly. The true complexity and art of software is finding the balance so you don't curse your past self 5 years from now when everything changes
Proper-Ape@reddit
It's simple - is the ongoing maintenance cost of that dependency worth it for the amount of code you use from it? If the answer is no, you don't add it, if the answer is yes, then add it.
bartosaq@reddit
At least now I have UV so I can fetch them fast.
Legitimate_Sun1783@reddit (OP)
Speed is nice, but I wonder if faster tooling just encourages even more dependencies.
Do you feel like tools like UV help reduce complexity… or hide it?