This could be one of those insightful posts that elegantly state an observation in a lasting way, and one that we'll repost every few years or so as an adage on

This could be one of those insightful posts that elegantly state an observation in a lasting way, and one that we'll repost every few years or so as an adage on programming. But there's a few reasons why I think it falls short: - It doesn't explore any of the reasons why the APIs -- the "how" -- age in a backwards-incompatible way. Not all cases are equal: a clean break is the surest way of dooming the old and ushering in the new, but this rarely means that old code was broken beyond all belief: even if the underlying framework made some simplified assumptions, the code probably worked okay most of the time, especially if we assume intelligent, competent developers familiar with with the underlying patterns, using a framework for its merits. A good hypothesis is that frameworks aren't solely there to help you solve problems with less code, but also to help others' understanding of the same codebase. - Yet even the article insinuates that we can't assume the previous all the time, because many developers understand design patterns by first coding themselves into a situation where they would be sorely needed -- this happened to me, for example. The same way the article's hypothetical developers acquire enduring knowledge, I didn't understand why I'd need dependency injection until I experienced firsthand the frustrations of handling dependent objects the naive way, and found myself re-invening it independently. This leads to the possibility that not all frameworks are picked solely for their design choices, but instead popularity, code availability, ecosystem health, press, advertising, or word-of-mouth may be factors. - If so, this still doesn't account for why new frameworks rise and all the time, which would logically begin disadvantaged by having smaller ecosystems, less popularity, less name recognition. What is there to gain by starting a new one? This is really a variation of point #1: there's a lot of subject matter to be explored here, and yet it's left unsaid.