5 ms·

I'm not a rails dev, but I believe that you are misconstruing his argument. It is not about inevitable complexity, but about the ownership of that complexity. I

by jamra 10y ago

I'm not a rails dev, but I believe that you are misconstruing his argument. It is not about inevitable complexity, but about the ownership of that complexity. If you are able to control the side effects part of development, you can control how it scales and debug it much more easily.

mooreds 10y ago
> It is not about inevitable complexity, but about the ownership of that complexity. I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application. Why? Because we owned all the complexity and couldn't support it. Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.
- ethbro 10y ago
  Those who trade for buried complexity are doomed to start digging whenever they discover an edge case. Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.
- philwelch 10y ago
  I've never seen a ten year old Rails application, but from the Rails applications I have seen, I'm horrified by the thought of how it would look after that long.
  - pimeys 10y ago
    I've been in a company that let their Rails applications grow for 7 years. Believe me, the oldest code was not pretty to read and almost impossible to refactor. When we finally had a real frontend team, the only way out was to reimplement the apps with a new architecture. At one point I realized, I should not stick into one language and one framework. Ruby is good to know, but I'm better if I can also tackle Scala, Java, Rust, OCaml, Haskell, Python and so on. Also happier, I'd say... I can now choose the best tool for the job.
dagw 10y ago
Having worked on systems like that, the problem is that you end up in a situation where there are literally two people in the world who can answer questions about how something works and integrating other third party libraries or solutions becomes harder and harder.
Double_Cast 10y ago
I have a third interpretation: I think Solnic was complaining about a lack of diversity in the Ruby ecosystem. The most salient part of the post was (imo) the paragraph regarding how Merb was subsumed into Rails, instead of continuing to compete against Rails. Rails is essentially a monopoly. > It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable. If projects such as Merb were more common, maybe Solnic could leave Rails without abandoning Ruby.

by jamra 10y ago

mooreds 10y ago

> It is not about inevitable complexity, but about the ownership of that complexity. I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application. Why? Because we owned all the complexity and couldn't support it. Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.

ethbro 10y ago
Those who trade for buried complexity are doomed to start digging whenever they discover an edge case. Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.
philwelch 10y ago
I've never seen a ten year old Rails application, but from the Rails applications I have seen, I'm horrified by the thought of how it would look after that long.
- pimeys 10y ago
  I've been in a company that let their Rails applications grow for 7 years. Believe me, the oldest code was not pretty to read and almost impossible to refactor. When we finally had a real frontend team, the only way out was to reimplement the apps with a new architecture. At one point I realized, I should not stick into one language and one framework. Ruby is good to know, but I'm better if I can also tackle Scala, Java, Rust, OCaml, Haskell, Python and so on. Also happier, I'd say... I can now choose the best tool for the job.

dagw 10y ago

Having worked on systems like that, the problem is that you end up in a situation where there are literally two people in the world who can answer questions about how something works and integrating other third party libraries or solutions becomes harder and harder.

Double_Cast 10y ago

I have a third interpretation: I think Solnic was complaining about a lack of diversity in the Ruby ecosystem. The most salient part of the post was (imo) the paragraph regarding how Merb was subsumed into Rails, instead of continuing to compete against Rails. Rails is essentially a monopoly. > It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable. If projects such as Merb were more common, maybe Solnic could leave Rails without abandoning Ruby.