Am I the only one in the IT adjacent world who thinks the inverse of this is the larger problem (churn, NIH, reinventing the wheel) in software today?
Can you/anyone recommend any?
I mostly work in the android world and the chase for the new and shiny is real.
I see some new libraries get a lot of traction seemingly only because they are written in kotlin/coroutines, not because they offer a better solution (for the one I have in mind, they did not even bother trying to do a benchmark to compare it with the existing solutions).
The thing is, the Android dev ecosystem got WAY better in some aspects.
Having moved to some of the new and shiny, well implemented MVI/MVVM architectures backed by Rx or Flow are very robust and give a good framework to develop on.
You still have to fight back against the zealots yelling that solution x that works just fine should be replaced by solution y even though it would take months of engineering work and does not really improve anything you care about (e.g. a 5% diminution of bytecode size is not something that's worth spending weeks on, or a network stack that hand wavingly 'improves performances' with no benchmark made to actually ascertain where our hot paths are)
PS.: for the parts that got worse : the build system and Android Studio failed to scale quickly enough to keep up with the enormous increase of build complexity. As a result they are slowly become less and less useable for large projects.
Sadly, it takes a lot more skill and courage to say the following in a way that other stakeholders care about: "We should use this tool because when I started using it, data flows were clear in a way that finally silenced some of the anxiety that I don't know what the fuck I'm doing and I am going to ruin everything."
However, it's always a challenge. For example, sometimes you have subsystems that are begging to be retired. For example, on one system we're maintaining about 20 KLOC of GWT code. For the last 10 years or so, it hasn't really been worth moving away from it, but there will be a day (that is rapidly approaching, I think) where the cost of supporting a mostly abandoned Java framework that compiles into JS outweighs the risk and cost of slowly replacing it.
There's a real difference between being pissed off with the choices your predecessors made, or lusting after the new, hot framework and saying: nope... this just isn't viable any more. Planning that transition isn't easy either. Again, it's one of the reasons I enjoy this kind of work.
And sometimes, you even just decide that you're going to work with what you've got. Ironically, though, this usually involves more churn, NIH and reinventing the wheel because code written 20 or 30 years ago did not have the facilities that we desire in modern development. You think, I'd love to enjoy the benefits of that new framework, but there ain't no way that we'll be able to use it. How do I get the benefits using the code I already have? Answer: you study what other people are doing and you build the same damn thing in your environment. Nobody builds the new-shiny for old stuff so if you want it, you have to build it yourself.
I enjoy bonsai trees. As trees grow, the branches become out of scale with the trunks. You can imagine that if your trunk is the size of a pencil, it doesn't take long for the branches to catch up. So if you want a tree that is in scale, you are constantly having to prune off the branches and grow new ones. There is a saying that a bonsai tree is never finished until it is done. Code is the same way. There is no such thing as avoiding churn -- unless you are truly trying to kill off your project. You always have to prune off branches and grow new ones, otherwise development will slowly grind to a halt -- the challenge of adding functionality without changing the code base getting to be more and more complex. But if you prune your branches before they grow you will end up with a stick in a pot. Or if you decide that you want to grow out every bud that pops out, then you will have an impenetrable mass of confusion. Deciding which branches to grow and which branches to prune, unfortunately requires good taste.