The fundamental truth of software is that it is much easier to write than it is to read. So it's often better, from the developer's perspective, to reimplememe

The fundamental truth of software is that it is much easier to write than it is to read. So it's often better, from the developer's perspective, to reimplemement a solution than to maintain refactor an existing legacy solution, even if your re-implementation ends up being inferior (which it almost always will at the beginning). So the reason why software cycles is that pioneers roll out some new tech, it gathers momentum, over time it becomes complex, it becomes harder for new developers to understand it, until a breaking point is reached and the new guys splinter off to make their own version from scratch, repeating the cycle. Yes, this is extremely wasteful, and it's hell on end-users, but there is forward progress, even if it's of a two-steps forward one-step back variety. Frankly, I don't see this situation changing as long as developers are sought after, which they pretty much always will be. If decision making is handed over to the sales and marketing folks, they will make even worse mistakes. It would be nice if there was a "stable software" movement similar to a "free software" movement. One that championed backwards compatibility and preservation of APIs and the user experience above all. Then customers would at least have a choice as to whether to get a dynamic or stable library/application/service. Apropos: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...