3 ms·

I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweig

by wg0 4y ago

I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django

ecshafer 4y ago
At Shopify we also are basically always on the bleeding edge of all Rails and Ruby versions. By always moving forward it makes each improvement much smaller
- sjs 4y ago
  Plus Shopify and GitHub must drive most development of Rails so it’s basically an in-house dependency to some extent. I know that’s simplifying things.
wlll 4y ago
As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.
- pmontra 4y ago
  I have customers with a mix of small Rails projects in version 6 or 7. I told one this week that we could use AR's encrypts :field to encrypt some fields in the database, but that project is Rails 6 and that feature is added by Rails 7. We could add the code to handle it because it's small, but customer decided not to encrypt the field and wait until (if!) the project moves to Rails 7.
  - wlll 4y ago
    I wouldn't say that's locked though. The place I currently work is on 6.1. We're not locked to it, we're going to upgrade, but in a few weeks or so. I can understand the reason to put off encrypting the field too. Upgrades, or backporting, are just work like any other project and I guess that other things for now take preference. After all, before field encryption came along the risk balance calculation had already been done (even if only implicitly) that storing the field unencrypted in the database was safe enough. The availability of encrypted fields doesn't change that, though making some things safer doesn't necessarily fall neatly into the "requirements" bucket despite being a good idea.
- Manfred 4y ago
  You have worked on a few projects that were behind a few major versions and needed considerable effort to be updated :)
  - wlll 4y ago
    Sure, though I still wouldn't say they were "locked", though what that means is somewhat subjective :) There was still a will and, with a strategy, success in upgrading. I've not been anywhere that has rolled out Rails LTS for instance, or just given up. The place you worked with me last year did a Rails 6.0 -> 6.1 and it took less than a week for one person, 6.1 -> 7.0 should be pretty similar.
- AlchemistCamp 4y ago
  Github itself used to be. They ran a custom fork of Rails 2.3 for years rather than go through the pain of upgrading to Rails 3. By the time they finally did, Rails had already moved on. It took Github a full eight years to get caught up after that fateful decision in 2010 to hold off on Rails 3.
  - wlll 4y ago
    Eileen, who used to work at Github, did a talk on the upgrade https://www.youtube.com/watch?v=ZrcPoRx_kQE https://www.youtube.com/watch?v=ZrcPoRx_kQE
  - nomilk 4y ago
    What were the sticking points that made the 2.3 -> 3 upgrade so tough?
    - kodah 4y ago
      In the article they mentioned they had a lot of patches to rails. They effectively made a fork. At enterprises it can be seen as not worth it to go through getting your changes merged in because it can take a long time. Once you make that decision, you're entrenched far more than one may realize.
    - aaronbrethorst 4y ago
      2.3 -> 3 saw the Rails and Merb projects merge, and a ton of changes to remove some of the most unmaintainable magical elements of Rails. https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-rails-3-d25c7b390fa1 https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-...
that_guy_iain 4y ago
The costs of running of the main branch outweighs the cost of waiting until there is a new release and upgrading then. Even if you're dealing with a stable framework that has good Backwards Compatability.
re-thc 4y ago
> That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. The cost of not upgrading is always the worst option. It's just that those making the decisions might not have the same stakes. It has nothing to do with technology and happens in every situation. Often you're just not even aware of what these costs are because you're wired to work around it. It just feels right to continue that workaround including continuing to hire and expand when it reality it's just more overhead.
- tyre 4y ago
  nothing is always. Consider moving to an SOA. Rather than upgrading a monolith when the engineering team knows that it’ll gradually have pieces pulled out of it, use that effort on the migration.
kybernetyk 4y ago
I think this is mostly a consequence of using dynamic typed languages.
- vc8f6vVV 4y ago
  We recently upgraded our pretty large enterprise Scala codebase from Cats v1 to Cats v2. Static typing does help, but there are tons of other problems. One of them is lack of conventions like in Ruby on Rails, which can easily be much worse than dynamic typing in the presence of conventions (provided that conventions are followed -- rarely the case).
ilyt 4y ago
I start to think that big breaking changes to "improve" the core are never the way to go for big framework. You're essentially making new framework with old name at that point.
andrewmutz 4y ago
It is pretty common for companies to not be locked in to an old version of a framework. Sounds like this is a good question to ask companies when you're interviewing, since it probably can act as a proxy for a lot of other engineering habits.
hbrn 4y ago
That's because most teams don't have a clear tech ownership: everybody wants to upgrade but nobody can justify it to the management or even plan for it. I found framework and runtime "freshness" to be a good metric of company engineering culture.
acedTrex 4y ago
You need a culture that values upgrades not for new features but for future proofing
danjac 4y ago
My advice is to set up things as best you can right from the start, to make upgrading a relatively painless process. For example: - Good test coverage (particularly for critical points of your application) including CI pipeline - Use dependabot or similar to make sure you get alerts for any critical updates (like security patches) - Practice good dependency "hygiene" - only add a dependency when you really need it, and do vetting to ensure it's well-supported, has been updated recently, etc. - Regularly audit and remove dependencies - when a library author declares they are sunsetting their project, plan on a replacement (even if that is, worst case, a fork). Remove dependencies which are no longer used in your code. - Separate out your development/testing/production dependencies - Use a good dependency manager: for example in Python, use Poetry or pip-tools or similar, rather than manually updating requirements.txt files yourself - Update early and often: other than dependabot make it a maintenance task to check for updates at least once a week. Use managers, scripts etc to make this as easy and painless as possible. Obviously if you are inheriting a legacy project you have to deal with the cards you are dealt, but these are a good target to move towards even with an old codebase.

by wg0 4y ago

ecshafer 4y ago

At Shopify we also are basically always on the bleeding edge of all Rails and Ruby versions. By always moving forward it makes each improvement much smaller

sjs 4y ago
Plus Shopify and GitHub must drive most development of Rails so it’s basically an in-house dependency to some extent. I know that’s simplifying things.

wlll 4y ago

As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.

pmontra 4y ago
I have customers with a mix of small Rails projects in version 6 or 7. I told one this week that we could use AR's encrypts :field to encrypt some fields in the database, but that project is Rails 6 and that feature is added by Rails 7. We could add the code to handle it because it's small, but customer decided not to encrypt the field and wait until (if!) the project moves to Rails 7.
- wlll 4y ago
  I wouldn't say that's locked though. The place I currently work is on 6.1. We're not locked to it, we're going to upgrade, but in a few weeks or so. I can understand the reason to put off encrypting the field too. Upgrades, or backporting, are just work like any other project and I guess that other things for now take preference. After all, before field encryption came along the risk balance calculation had already been done (even if only implicitly) that storing the field unencrypted in the database was safe enough. The availability of encrypted fields doesn't change that, though making some things safer doesn't necessarily fall neatly into the "requirements" bucket despite being a good idea.
Manfred 4y ago
You have worked on a few projects that were behind a few major versions and needed considerable effort to be updated :)
- wlll 4y ago
  Sure, though I still wouldn't say they were "locked", though what that means is somewhat subjective :) There was still a will and, with a strategy, success in upgrading. I've not been anywhere that has rolled out Rails LTS for instance, or just given up. The place you worked with me last year did a Rails 6.0 -> 6.1 and it took less than a week for one person, 6.1 -> 7.0 should be pretty similar.
AlchemistCamp 4y ago
Github itself used to be. They ran a custom fork of Rails 2.3 for years rather than go through the pain of upgrading to Rails 3. By the time they finally did, Rails had already moved on. It took Github a full eight years to get caught up after that fateful decision in 2010 to hold off on Rails 3.
- wlll 4y ago
  Eileen, who used to work at Github, did a talk on the upgrade https://www.youtube.com/watch?v=ZrcPoRx_kQE https://www.youtube.com/watch?v=ZrcPoRx_kQE
- nomilk 4y ago
  What were the sticking points that made the 2.3 -> 3 upgrade so tough?
  - kodah 4y ago
    In the article they mentioned they had a lot of patches to rails. They effectively made a fork. At enterprises it can be seen as not worth it to go through getting your changes merged in because it can take a long time. Once you make that decision, you're entrenched far more than one may realize.
  - aaronbrethorst 4y ago
    2.3 -> 3 saw the Rails and Merb projects merge, and a ton of changes to remove some of the most unmaintainable magical elements of Rails. https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-rails-3-d25c7b390fa1 https://medium.com/ruby-on-rails/upgrading-a-rails-2-app-to-...

that_guy_iain 4y ago

The costs of running of the main branch outweighs the cost of waiting until there is a new release and upgrading then. Even if you're dealing with a stable framework that has good Backwards Compatability.

re-thc 4y ago

> That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. The cost of not upgrading is always the worst option. It's just that those making the decisions might not have the same stakes. It has nothing to do with technology and happens in every situation. Often you're just not even aware of what these costs are because you're wired to work around it. It just feels right to continue that workaround including continuing to hire and expand when it reality it's just more overhead.

tyre 4y ago
nothing is always. Consider moving to an SOA. Rather than upgrading a monolith when the engineering team knows that it’ll gradually have pieces pulled out of it, use that effort on the migration.

kybernetyk 4y ago

I think this is mostly a consequence of using dynamic typed languages.

vc8f6vVV 4y ago
We recently upgraded our pretty large enterprise Scala codebase from Cats v1 to Cats v2. Static typing does help, but there are tons of other problems. One of them is lack of conventions like in Ruby on Rails, which can easily be much worse than dynamic typing in the presence of conventions (provided that conventions are followed -- rarely the case).

ilyt 4y ago

I start to think that big breaking changes to "improve" the core are never the way to go for big framework. You're essentially making new framework with old name at that point.

andrewmutz 4y ago

It is pretty common for companies to not be locked in to an old version of a framework. Sounds like this is a good question to ask companies when you're interviewing, since it probably can act as a proxy for a lot of other engineering habits.

hbrn 4y ago

That's because most teams don't have a clear tech ownership: everybody wants to upgrade but nobody can justify it to the management or even plan for it. I found framework and runtime "freshness" to be a good metric of company engineering culture.

acedTrex 4y ago

You need a culture that values upgrades not for new features but for future proofing

danjac 4y ago

My advice is to set up things as best you can right from the start, to make upgrading a relatively painless process. For example: - Good test coverage (particularly for critical points of your application) including CI pipeline - Use dependabot or similar to make sure you get alerts for any critical updates (like security patches) - Practice good dependency "hygiene" - only add a dependency when you really need it, and do vetting to ensure it's well-supported, has been updated recently, etc. - Regularly audit and remove dependencies - when a library author declares they are sunsetting their project, plan on a replacement (even if that is, worst case, a fork). Remove dependencies which are no longer used in your code. - Separate out your development/testing/production dependencies - Use a good dependency manager: for example in Python, use Poetry or pip-tools or similar, rather than manually updating requirements.txt files yourself - Update early and often: other than dependabot make it a maintenance task to check for updates at least once a week. Use managers, scripts etc to make this as easy and painless as possible. Obviously if you are inheriting a legacy project you have to deal with the cards you are dealt, but these are a good target to move towards even with an old codebase.