[octernion]

as a counterpoint, i work at instacart, where we have rails apps (we broke our application into "macroservices" several years ago) each around ~50-200k LOC which we have maintained for 5+ years while growing exponentially (customer base) and not exponentially (engineering headcount :)

i've talked to other companies that have done similar things.

where are you getting any of this from?

[pka]

From experience.

I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests.

As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.

[octernion]

"Otherwise: don't bother." is a pretty strong statement and i think in the distinct minority.

how much of your statement is driven by that one example? that seems like a broken process or a poorly designed system (orthogonal to rails) than anything else...

[pka]

> i think in the distinct minority

I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.

> that seems like a broken process or a poorly designed system

I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument. In a perfect world with perfect, non-changing requirements, no deadlines and understanding clients you can probably make Brainfuck maintainable :)

[drspacemonkey]

>I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument

If you've got a dysfunctional team and poor design, the language/framework choice isn't gonna help you. There isn't a framework in the world that will save you from tight coupling, lack of styleguide, business logic scattered all over the place, poor test suites, or monoliths made by bootcamp graduates.

[octernion]

> I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.

fwiw i voted you up because i strongly believe in constructive discussion around these things. i don't think you should take that as a signal that folks support this position.

> I'm sorry, but saying that as long as your process isn't broken...

i'm merely saying that from several shops i've worked at, including instacart, with many 10k+ lines of code rails codebases, i've never seen problems like what you've described and it sounds pathological for that specific application/company.

again my (and many others') point is that rails is absolutely maintainable, even at massive scale, and even in a world with ever-changing requirements, hard deadlines, and very loosely-understanding clients, and that all that takes is doing rails the "right way" (a comprehensive test suite, reasonable architectural design), and that it is still massively productive.

[TomK32]

Isn't a exp growing user base more a problem for the support support rather than the developers?