6 ms·

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

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

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