The problem isn't that tech is moving too fast. It's churning too fast. How many copycats, changed (i.e. broken) APIs, new ranking algorithms and UIs do we get for every one tiny bit of actual forward movement? All this "disruption" for its own sake sucks the time and energy out of the people who actually do all the innovating. When half of every release is about fixing broken dependencies and half of every sales cycle is about answering FUD from "competitors" who fail on the very fundamentals, that's not progress. It makes me want to get out of the business too.
Right. This "move quickly and break stuff" can work, barely, in a single organisation. Once you have inter-organisation dependencies which constantly break, and is the current situation, you rapidly head towards an unproductive tarpit.
This is one of my stock objections to package management "solutions" such as Maven. By reducing the friction for change on the part of implementers it pushes the burden on to consumers of APIs to adapt. "Just update your package - it takes two seconds" is the eternal lie of such systems. Package managers by themselves aren't bad, but the resulting mindset is.
I think some people in this thread are being a bit eager about change-for-its-own-sake. But change isn't in itself progress, it isn't in itself betterment. It might as well be a distraction or a regression.
I see a reason to celebrate novel concepts and technologies, and incremental improvements. I don't see a reason to celebrate yet another technology with 90% of the power of the previous technology, only 50% of the problems of the previous tech, but with a whole slew of problems that that other technology from 7 years ago brought up and that the previous technology fixed. And with a packaging that is similar enough to not be challenging, yet different enough to have to make a concentrated, droning effort in order to iron out any misunderstandings or surprising behaviour.
