It's amazing how many apps for which this is true. I've spent more time in Rails land upgrading older microservices to latest rails. It's pretty crappy work actually.

I too have spent a ton of time doing this. It's a product of Rails architecture and the prevailing design philosophies in the Rails community.

I am fine with it, I do this as a service for other companies who's developers are too busy with feature work.

Being "too busy with feature work" is exactly the mindset that forces us to spend months and months of developer time every couple of years to upgrade Rails and an ever growing list of other gem dependencies.

It is hard for managers to organize developers and to uphold for good practices. That is why I created a service so people would not feel guilty, just hire us and we take care of things for you. :)

Nice for you. Not so nice for the companies wasting their money on paying you. Yeah, managing software teams is hard. But paying contractors every year to upgrade Rails is malpractice. Can you honestly say that you are capable of going into these legacy systems with thousands of lines of code and upgrading all of their gems, including Rails, without causing regressions? Maybe for a small project your approach is okay but it doesn't scale.

If you know rails well and keep current, upgrading is perfectly straightforward, if uninspiring, work.

It's a janitorial service of sorts, and it's totally appropriate for some corps to contract it out. It allows the developers with the best knowledge of the business to focus on that, where value is created. Regressions are mitigated by a strong culture of testing.

I've spent many months upgrading legacy Rails services. One particular project was upgrading several microservices from Rails 3.1 to Rails 4. The projects made use of Rspec, Test::Unit, and Capybara. There were unit tests, integration tests, and UI tests. There were over 5000 specs in total. The project also used many gems in production to accomplish its tasks. When you are forced to uprgrade: the testing frameworks themselves, the ORM, the web framework, static asset building tools, libraries for managing file uploads, map rendering, etc, all in one go, it's nearly impossible to get it 100% right. We upgraded minor versions one by one. We read the Rails release notes and any gems that had them. Every time we bumped a Rails version we broke thousands of tests. Even after months of meticulous work we had only managed to upgrade 3 of the 4 services up to Rails 4.0, with another stuck on 3.2. Is it possible to work this way? Sure. But it's insane and costly when you let it get this bad. I've yet to work on a large Rails project on a team that outsources their upgrades where upgrading was "perfectly straight forward". It sounds like you work for a company that actually cleans house. A company like that has no need to hire OP.

I actually went through that several times. It is not easy and requires specific expertise, like you said. Sometimes it makes sense to refactor parts. Microservices are not the only way to refactor. I like Trailblazer for example who for bigger codebases adds another layer of discipline.

Just wondering how much of this upgrade pain is Rails-specific? How about Spring, Play and Django? What's so different about Rails?

I ran into such serious issues with Django and Django-CMS that we were unable to upgrade a Django 1.7 app to 1.8 without a ton of work and the possibility of data corruption. "Kitchen sink" frameworks like the ones mentioned above often lead to issues like this. I don't use Play framework any more when writing Scala. That being said, Rails truly was the pioneer for this type of web application programming. Many of the other frameworks are just copy cats.

Yes, I had a feeling Rails was getting singled-out unfairly. There's nothing about Rails which is more monolithic than, say, Spring, Django, Play or Laravel.

Put another way: If you're always outsourcing work like upgrading Rails versions so that your devs can focus on "features" they will never learn which design decisions they are making are extremely costly in the long run. Like, hmm, maybe I shouldn't include 4 gems just to build and test my JavaScript. Or, hmm, maybe I shouldn't write this code in a way that leaks ORM details. Testing culture is great. But it is not an antidote for kicking-the-can-down-the-road culture.

That I can agree with. I've been using rails since version 0.9, and my predisposition is to use as few gems as possible.

Managed properly, rails and ecosystem churn is manageable. Managed poorly, it becomes reasonable to bring in an expert to repair your neglect.

But it's definitely true that rails culture doesn't make itself easy to manage.

I think you are very narrow minded here. It takes considerable cost to hire developers if you have code debt and the kind you get are quite different. It is really not something that is wasteful, quite the contrary.

Also, I have yet to meet a team that has all the developers it wants, with all the expertise they desire. Maybe FB and Google, most other places need to focus their talent on what will bring best value.

It actually makes more sense on bigger codebases then on smaller.

They would get much more value out of their team if they took the time to help them to be proper software developers. Companies these days do not focus nearly enough on mentorship and continuing education. Instead they hire a team, treat them like code monkeys, then pay big bucks to expensive contractors to do big upgrades and rewrites.

I agree with you completely, they spend a ton of time to hire you, only to ignore you the second you say yes :), or give you completely innapropriate working conditions. So all your expertise you were so happy to get and bring to the table, can't use it.

Are you hiring?

:) Not at the moment, but feel free to connect /w.