9 ms·

A lot of this boils down to the constant churn in frameworks, instrumentation, programming languages. Developers don't have time to master one way of doing thin

A lot of this boils down to the constant churn in frameworks, instrumentation, programming languages. Developers don't have time to master one way of doing things, it's just a constant lava layer of crap. I took the time to learn how to build and maintain Ruby on Rails systems, hoping it would be the ticket to a fun, manageable career. Any project I worked on was an island of sustainable, fast development where the team finished the sprint's work in a few days. I knew where the bottlenecks were should the project need to scale, and scaling issues never took down the site completely. Only to throw all that expertise away when it was just decided to replatform one day. Because I guess stable just wasn't good enough. After it happened twice, well, might as well go into devops. Y'all are gonna need it.

burntoutfire 6y ago
> After it happened twice, well, might as well go into devops. My observation of the devops world is that the rotation of technologies and frameworks there is faster than in backend development.
- cagenut 6y ago
  True but imho its somewhat of a fan-out or at the very least knock-on effect. The explosion in devops complexity is a necessary byproduct of the explosion of projects that adopt new languages, runtimes, datastores, etc. No one ever fully deletes and retires the old system, so the overall environmental complexity grows exponentially. The tools it takes to solve those exponentially larger problems (k8s) look ridiculous when you consider them in the context of "a rails app with some node stuff". But they make perfect sense when you say "every quarter or two, for a decade, a dev team has adopted a new component or two into the stack. less than three of which have ever been deleted."
- moreaccountspls 6y ago
  Yes, but there at least is some genuine innovation going on. The backend frameworks are just churn for solving the same boring and lucrative business problems in new, fashionable ways.
Nbox9 6y ago
If you like Ruby on Rails so much, why don’t you find a job programming Ruby on Rails? There are so many.
- mandelbrotwurst 6y ago
  He mentioned that he had a job doing that, but the company moved away from the framework without technical justification. He could find another, but there would be no guarantee that the same thing wouldn't happen again.
  - Nbox9 6y ago
    > the company moved away from the framework without technical justification I think this alone is enough justification to look for a new place to work, but I’m just a job hopping millennial.
    - vinceguidry 6y ago
      I did. Asked to be moved to a different client. Still there.
- nthj 6y ago
  My experience is that nobody actually does things The Rails Way, which is where most of the benefits come in. No, they’ll start out in Rails such that their underlying data model evolves into a huge mess (because Rails guards against most problems in the code layer, so the data model problems don’t really appear as bugs yet), and then some resume-driven developer will push for serverless or microservices to solve scalability problems (when the actual bottleneck is the database and the data model, not Rails), and now you’re left managing this Frankensteinish “rails” SPA beast that could be rewritten as a proper database schema and a 5K LOC Rails app, but there’s too much change control process to actually achieve that.
  - chrischattin 6y ago
    Rails does so much of the plumbing work for you (and does it really well) that it’s a good smell test that if you’re not working on something that the user sees, you’re probably reinventing the wheel.
throwlogon 6y ago
> I guess stable just wasn't good enough I suspect that's meant to be rhetorical, but from a business perspective, was stable good enough? Sometimes what works now won't be competitive in the near future.
- tluyben2 6y ago
  > Sometimes what works now won't be competitive in the near future. What do you mean by that? I can understand in terms of hiring devs, this is true, but any other reason I would be curious about. Because I work with/in many companies, I see a lot of different tech and competitive is usually just what the team knows best. So unless you are making a new team, I cannot phantom why you would switch. Java with Servlets/Spring and C# with asp.net have been competitive for almost 2 decades; maybe some people can shave off a few minutes here and there but in the grand scheme of a serious company with a serious project (500k loc+) it is not going to matter. There are exceptions as for instance machine learning but those gaps close and this was about web frameworks.
  - TedDoesntTalk 6y ago
    Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.
    - binsh 6y ago
      Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true. You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour. Maybe talent means something else when nothing is at stake, but I'd argue that a talented engineer knows that when a product works and makes money, and the tech stack isn't prohibitive of those goals, it doesn't really matter what it's written in. In fact, I see trend-chasing developers as liabilities, because they're the ones who will replace everything every six months while you bleed money.
tluyben2 6y ago
I had the same issue with Rails as I have with Node : the churn is detriment to long standing projects. Most projects I do run for years and even decades; you go run an update for security for Rails code that is 10 years old. It is a nightmare. I did not have issues like that with php, asp.net or spring.
- chrischattin 6y ago
  My experience has been the opposite. The Rails ecosystem makes updates straight forward and is very well documented. Been running various Rails apps for almost a decade now.
  - dmurray 6y ago
    It's pretty good for incremental updates. It only asks a few hours a year to manage those. Not so good when you want to upgrade a 5-year-old system. I inherited a reasonably well-built Rails app deployed with Ruby 2.2.1 and would like to update it, if only for security reasons. I can't even run that on a recent Ubuntu. On a system where I can run it, I run into dependency hell with the gems - need to upgrade some, pin lower versions of others. Possibly that could have been handled with pinned dependency versions the first time round, but that breaks the regular upgrade process.
    - tluyben2 6y ago
      That is indeed what I meant; I had to create debootstraps to even get it running on my laptop. And many of the gem updates broke the apis completely for no reason (move fast and don’t care?) I do not know: I remember a security update where the new version renamed most of the api methods while there was no reason to do so. I understand you can add new methods to keep backward compat; here they actually renamed functions so it was not backwards compatible and you had to change everything. Simply put; we can cry about java or c# or php (raw php: not laravel; it has the same issues) but I can run 15 year old code on my current Ubuntu and it works fine. Maybe I need to change a few things but I do not have to rewrite a lot of it; it is more find/replace than anything. The feeling that software has to work in 50 years is important. Incremental updates are expensive and not needed for most companies, so software needs to support major version updates over decades. We know that now...

burntoutfire 6y ago

> After it happened twice, well, might as well go into devops. My observation of the devops world is that the rotation of technologies and frameworks there is faster than in backend development.

cagenut 6y ago
True but imho its somewhat of a fan-out or at the very least knock-on effect. The explosion in devops complexity is a necessary byproduct of the explosion of projects that adopt new languages, runtimes, datastores, etc. No one ever fully deletes and retires the old system, so the overall environmental complexity grows exponentially. The tools it takes to solve those exponentially larger problems (k8s) look ridiculous when you consider them in the context of "a rails app with some node stuff". But they make perfect sense when you say "every quarter or two, for a decade, a dev team has adopted a new component or two into the stack. less than three of which have ever been deleted."
moreaccountspls 6y ago
Yes, but there at least is some genuine innovation going on. The backend frameworks are just churn for solving the same boring and lucrative business problems in new, fashionable ways.

Nbox9 6y ago

If you like Ruby on Rails so much, why don’t you find a job programming Ruby on Rails? There are so many.

mandelbrotwurst 6y ago
He mentioned that he had a job doing that, but the company moved away from the framework without technical justification. He could find another, but there would be no guarantee that the same thing wouldn't happen again.
- Nbox9 6y ago
  > the company moved away from the framework without technical justification I think this alone is enough justification to look for a new place to work, but I’m just a job hopping millennial.
  - vinceguidry 6y ago
    I did. Asked to be moved to a different client. Still there.
nthj 6y ago
My experience is that nobody actually does things The Rails Way, which is where most of the benefits come in. No, they’ll start out in Rails such that their underlying data model evolves into a huge mess (because Rails guards against most problems in the code layer, so the data model problems don’t really appear as bugs yet), and then some resume-driven developer will push for serverless or microservices to solve scalability problems (when the actual bottleneck is the database and the data model, not Rails), and now you’re left managing this Frankensteinish “rails” SPA beast that could be rewritten as a proper database schema and a 5K LOC Rails app, but there’s too much change control process to actually achieve that.
- chrischattin 6y ago
  Rails does so much of the plumbing work for you (and does it really well) that it’s a good smell test that if you’re not working on something that the user sees, you’re probably reinventing the wheel.

throwlogon 6y ago

> I guess stable just wasn't good enough I suspect that's meant to be rhetorical, but from a business perspective, was stable good enough? Sometimes what works now won't be competitive in the near future.

tluyben2 6y ago
> Sometimes what works now won't be competitive in the near future. What do you mean by that? I can understand in terms of hiring devs, this is true, but any other reason I would be curious about. Because I work with/in many companies, I see a lot of different tech and competitive is usually just what the team knows best. So unless you are making a new team, I cannot phantom why you would switch. Java with Servlets/Spring and C# with asp.net have been competitive for almost 2 decades; maybe some people can shave off a few minutes here and there but in the grand scheme of a serious company with a serious project (500k loc+) it is not going to matter. There are exceptions as for instance machine learning but those gaps close and this was about web frameworks.
- TedDoesntTalk 6y ago
  Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.
  - binsh 6y ago
    Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true. You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour. Maybe talent means something else when nothing is at stake, but I'd argue that a talented engineer knows that when a product works and makes money, and the tech stack isn't prohibitive of those goals, it doesn't really matter what it's written in. In fact, I see trend-chasing developers as liabilities, because they're the ones who will replace everything every six months while you bleed money.

tluyben2 6y ago

I had the same issue with Rails as I have with Node : the churn is detriment to long standing projects. Most projects I do run for years and even decades; you go run an update for security for Rails code that is 10 years old. It is a nightmare. I did not have issues like that with php, asp.net or spring.

chrischattin 6y ago
My experience has been the opposite. The Rails ecosystem makes updates straight forward and is very well documented. Been running various Rails apps for almost a decade now.
- dmurray 6y ago
  It's pretty good for incremental updates. It only asks a few hours a year to manage those. Not so good when you want to upgrade a 5-year-old system. I inherited a reasonably well-built Rails app deployed with Ruby 2.2.1 and would like to update it, if only for security reasons. I can't even run that on a recent Ubuntu. On a system where I can run it, I run into dependency hell with the gems - need to upgrade some, pin lower versions of others. Possibly that could have been handled with pinned dependency versions the first time round, but that breaks the regular upgrade process.
  - tluyben2 6y ago
    That is indeed what I meant; I had to create debootstraps to even get it running on my laptop. And many of the gem updates broke the apis completely for no reason (move fast and don’t care?) I do not know: I remember a security update where the new version renamed most of the api methods while there was no reason to do so. I understand you can add new methods to keep backward compat; here they actually renamed functions so it was not backwards compatible and you had to change everything. Simply put; we can cry about java or c# or php (raw php: not laravel; it has the same issues) but I can run 15 year old code on my current Ubuntu and it works fine. Maybe I need to change a few things but I do not have to rewrite a lot of it; it is more find/replace than anything. The feeling that software has to work in 50 years is important. Incremental updates are expensive and not needed for most companies, so software needs to support major version updates over decades. We know that now...