I keep reading (and feeling it myself) that in software always reinventing the wheel when it comes to software.
Of course, a lot of it is due to opinionated (design) decisions. Or profit. But if we all had to agree on things that are solved & done and not to be touched again and would at most create a few small personal frictions (as there are either way), but which we can live with so that we really only build new software, Frameworks etc. for new things.
Let's imagine the existence of our planet depended on it.
What would the stack be? What composition of languages, processes & tools that would work "for everyone"?
Or if there was a set of rules that everyone had to adhere to, in which it says what is not to be reinvented, what do you think would be included?
It's only theoretical, of course, but I'm interested to see if there are even a few common denominators to identify on HN and what these are to people here.
In real life: the old library covers 80% of my use cases. The problem is that it's not extensible, so in order to add the remaining 20% I have to fork it. Moreover, it has a lot of extra features I don't want, but get in the way when adding my 20%, so it would be less work to rewrite the entire thing from scratch with only the features I need.
Either way, now there are 2 similar versions of the same thing. Then someone else encounters the same problem, except their wheel needs ridges for all-terrain, or their library must be in the language that the rest of their code is written in (and FFI sucks). Now there are 3 similar versions. And so on...
Why not just make a "one-size-fits-all" library which can be extended any way? People have tried and will continue trying, but what they end up producing is the definition of "over-engineered": a bloated mess which is buggy, inefficient, hard to understand, and still manages to only cover 95% of my use-cases.
Don't get me wrong, code reuse (even legacy code) is a good thing, and there are plenty of cases where developers would be better off using an existing library. Maybe they'd to write a bit of glue code to fit their purpose, maybe they'd need to sacrifice some performance or non-essential feature (which is probably performance-related and/or a dumb idea anyways), maybe they understand this but simply choose to spend time writing their own unnecessary library because it's more fun.
But as our world becomes more complex and competitive, especially in web-dev, those couple niche extra features or performance gains or developer pain-point mitigations that only a full rewrite would provide, become worthwhile enough to warrant the rewrite.