It's one thing to update your infrastructure and libraries. It's another to have to substantially rewrite everything in the process of doing so. I wouldn't kno

It's one thing to update your infrastructure and libraries. It's another to have to substantially rewrite everything in the process of doing so. I wouldn't know about this; I've never had to do it, with Rails sites at least. If that's a description of an upgrade of Rails apps, I think it is overblown frankly, unless it involves new developers coming in blind to an app and trying to update - in that situation, whatever the framework, there is going to be pain - the pain of not knowing the app or dependencies added to any upgrade glitches can lead to a lot of trouble. I do think the article made a mistake in mixing up security/infrastructure updates with framework and app updates. It comes off as vague, wooly and somewhat deceptive to the client. It's quite another to maintain, rewrite, and retain compatibility with existing apps and infrastructure. Done a fair bit of this (though less of the rewriting). Frankly, Rails is much like any other framework in this respect - things mostly change gradually, and they make a good effort at backwards compatibility, but it's not always perfect; it's not much worse than other frameworks, though I'm sure some others do a better job (with other tradeoffs). The move from 2-3 was the biggest, but even that wasn't particularly troubling for me - it could be harder with very large, complex apps, but those apps usually have a team looking after them and money to spend on upgrades/maintenance. The worst place to be in is coming in to a new app which is broken and out of date, or just badly structured, and trying to fix it - this pain occurs in any language that I'm familiar with, and I suspect that's the reason for a lot of rewriting. I have been guilty of this once or twice myself on other platforms, but sometimes (rarely) it is the right choice.