> (...) I’ll have mature teammates who understand the right tool for the right job. I
Honest question: what leads you to believe that Ruby on Rails, or even Ruby, is the right tool for the right job? You didn't even mentioned the job, so why do you automatically assume Ruby is the right tool?
Additionally, by ignoring popularity you're also ignoring availability of documentation and examples and mindshare. You're also ignoring experience, and prior onboarding into a language stack, which automatically means odds are anyone onboarding into the project will quickly be up and running.
Speaking as someone who was forced to onboard into a Ruby project just because a predecessor jumped on the bandwagon, the experience was an unmitigated disaster. A minor onboarding task that consisted of tweaking a hard codes settin in a module required me and a couple of colleagues to spend a few days a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with idiomatic Ruby, d) learning how to troubleshoot and debug Ruby applications, e) properly setup a software dev environment, and f) finally fix the issue.
If my predecessor opted to use Python instead of succumbing to bandwagons and resume-driven development practices, the same thing would take a couple of man/hours.
How does can this sort of snafu pass off as the right tool for the right job?
Sounds like this is less about whether RoR was the right tool for the job and more that no one other the implementer was familiar with Ruby/Rails (and maybe not even them).
This might mean that this wasn't the right tool _for your team_, but it's not a comment on what jobs are a good fit with RoR.
> Sounds like this is less about whether RoR was the right tool for the job and more that no one other the implementer was familiar with Ruby/Rails (and maybe not even them).
Isn't that already an operational problem? I mean, consider the mental burden alone of being forced to onboard to a completely different and relatively obscure tech stack, including the quirky programming language that serves as it's base, and all just to keep a web service up and running.
> a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with ..language.., d) learning how to troubleshoot and debug ... applications, e) properly setup a software dev environment, and f) finally fix the issue.
Applies with every language and framework one is not familiar with.
> If my predecessor opted to use Python instead of succumbing to bandwagons and resume-driven development practices, the same thing would take a couple of man/hours.
That's my opinion but after maintaining some large Rails apps and large Django apps, I would still take Rails any day. Just the testing quality and the batteries included makes it worth it, whereas the main downsides of Rails (speed and lack of typing) are also there anyways on a Django project.
That aside, if people building the project don't have any experience with what they are doing, it will be messy regardless of the framework or the language.
Holy crap! you were paid to work on a Rails app and you actually had to learn Ruby/Rails to get stuff done? The horror! I would seek compensation from my employer for that, not way is that legal.
I get the point, it's not completely invalid.
And still, calling Rails "obscure" is a stretch. In web dev world it's still a pretty dominant framework. There shouldn't really be any problem to hire Ruby guys afaik.
It sounds like more than RoR. Anecdata counterpoint: I’ve worked on a few RoR projects that were well architected and only took me a few days to fully ramp up.
I too have had experience after experience where every Ruby on Rails project in maintenance mode is a complete disaster.
It seems like it’s great for quickly building things, but it is unmaintainable, unless you wrote the thing. I am very flexible otherwise, but Ruby on Rails is banned from any project I’m involved in.
My experience is the opposite - Rails projects tend to have tests and maintaining is easy because the test suite is end to end and means something.
That said, Rails projects without tests aren't fun. Besides missing tests, I've also seen fat controllers, bad schema design, and not using Rubocop make more issues with maintenance, but usually I interpret as lack of understanding how to use Rails, not Rails being to blame.
Honest question: what leads you to believe that Ruby on Rails, or even Ruby, is the right tool for the right job? You didn't even mentioned the job, so why do you automatically assume Ruby is the right tool?
Additionally, by ignoring popularity you're also ignoring availability of documentation and examples and mindshare. You're also ignoring experience, and prior onboarding into a language stack, which automatically means odds are anyone onboarding into the project will quickly be up and running.
Speaking as someone who was forced to onboard into a Ruby project just because a predecessor jumped on the bandwagon, the experience was an unmitigated disaster. A minor onboarding task that consisted of tweaking a hard codes settin in a module required me and a couple of colleagues to spend a few days a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with idiomatic Ruby, d) learning how to troubleshoot and debug Ruby applications, e) properly setup a software dev environment, and f) finally fix the issue.
If my predecessor opted to use Python instead of succumbing to bandwagons and resume-driven development practices, the same thing would take a couple of man/hours.
How does can this sort of snafu pass off as the right tool for the right job?