5 ms·

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

by slimed 9y ago

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.

desireco42 9y ago
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. :)
- slimed 9y ago
  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.
  - quesera 9y ago
    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.
    - slimed 9y ago
      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.
      - cutler 9y ago
        Just wondering how much of this upgrade pain is Rails-specific? How about Spring, Play and Django? What's so different about Rails?
        slimed 9y ago
        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.
        cutler 9y ago
        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.
      - desireco42 9y ago
        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.
    - deleted 9y ago
      [deleted]
    - slimed 9y ago
      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.
      - quesera 9y ago
        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.
  - desireco42 9y ago
    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.
    - slimed 9y ago
      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.
      - desireco42 9y ago
        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.
- ChickeNES 9y ago
  Are you hiring?
  - desireco42 9y ago
    :) Not at the moment, but feel free to connect /w.

by slimed 9y ago

desireco42 9y ago

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. :)

slimed 9y ago
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.
- quesera 9y ago
  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.
  - slimed 9y ago
    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.
    - cutler 9y ago
      Just wondering how much of this upgrade pain is Rails-specific? How about Spring, Play and Django? What's so different about Rails?
      - slimed 9y ago
        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.
        cutler 9y ago
        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.
    - desireco42 9y ago
      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.
  - deleted 9y ago
    [deleted]
  - slimed 9y ago
    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.
    - quesera 9y ago
      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.
- desireco42 9y ago
  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.
  - slimed 9y ago
    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.
    - desireco42 9y ago
      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.
ChickeNES 9y ago
Are you hiring?
- desireco42 9y ago
  :) Not at the moment, but feel free to connect /w.