4 ms·

You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc

You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc; which is something you can't say publicly, and even if the company did, it would be heavily doctored to make a good impression on stakeholders. That's why I think the argument is a weak appeal to authority. Throw enough money at a problem, and you can scale anything involving computers. Notice how expensive is Heroku. But you can't add more team members to a project and expect things to go faster, which is where the real problem with Rails lies.

jemmyw 3y ago
I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience. The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively. I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it. At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way. Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.
- ulizzle 3y ago
  Just because you can’t square it with your experience doesn’t mean much. What you want to do is compare your experience with others. Rails can work well but it’s going to be expensive. Everything is a trade-off. Because Devs don’t see operating costs, they don’t feel the pain.
  - jemmyw 3y ago
    Seeing as developer salaries are the biggest cost and I just talked about how I've seen fewer developers deliver more over significant time with Rails your comment doesn't make any sense. Anyway both of our opinions are based on anecdote. It would be interesting to see an analysis on real data but I wouldn't trust that anyone could get that data from industry, correctly accounting for failures.
- 0xblinq 3y ago
  Your experience matches mine. 100% agree on this.
0xblinq 3y ago
Those metrics you’re asking for, I’ve seen them to vary wildly within the exact same stack at different companies, or even within the same company at different teams. I don’t think they have anything to do at all with the stack. I think they’re more related to the people, the working culture, the practices and in particular the rotation and the “happiness” within the team

jemmyw 3y ago

I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience. The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively. I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it. At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way. Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.

ulizzle 3y ago
Just because you can’t square it with your experience doesn’t mean much. What you want to do is compare your experience with others. Rails can work well but it’s going to be expensive. Everything is a trade-off. Because Devs don’t see operating costs, they don’t feel the pain.
- jemmyw 3y ago
  Seeing as developer salaries are the biggest cost and I just talked about how I've seen fewer developers deliver more over significant time with Rails your comment doesn't make any sense. Anyway both of our opinions are based on anecdote. It would be interesting to see an analysis on real data but I wouldn't trust that anyone could get that data from industry, correctly accounting for failures.
0xblinq 3y ago
Your experience matches mine. 100% agree on this.

0xblinq 3y ago

Those metrics you’re asking for, I’ve seen them to vary wildly within the exact same stack at different companies, or even within the same company at different teams. I don’t think they have anything to do at all with the stack. I think they’re more related to the people, the working culture, the practices and in particular the rotation and the “happiness” within the team