4 ms·

Ok let's be serious what does burned mean? My impression is that most people use Rails because it allows you to be very productive very quickly. Presumably that

Ok let's be serious what does burned mean? My impression is that most people use Rails because it allows you to be very productive very quickly. Presumably that means you know you're trading performance for productivity. Maybe you'll have to do a re-write of parts of your app in another language for performance reasons or because you need to perform some operations concurrently, but you know up front you're not choosing the language strictly because of its technical performance but instead because of business constraints. Keeping that in mind, were those companies really burned by Rails or were they making lazy decisions and not being honest about what their plan was for their software?

tdumitrescu 12y ago
I don't think it's about performance. It's about the glut of inexperienced, underskilled Ruby devs landing seemingly simple gigs where they patch together unmaintainable Rails spaghetti - ultimately saddling clients/employers with a heap of technical debt and hobbling future devs who come to these projects.
- sanderjd 12y ago
  This is a case of getting what you're willing to pay for. Great work is expensive because it takes a lot of experience to do, and there are a lot of opportunities for those with a lot of experience. But if you're willing to sacrifice the "great work" part, there are plenty of people out there with less experience doing (potentially) less great work for less cost. Everybody would like above market work for below market cost, but it doesn't tend to work that way.
  - jalfresi 12y ago
    I see what you're getting at but when Ruby/Rails was all new and shiny a couple of years back I knew an awful lot os junior/inexperienced devs who quite permanent jobs to go freelance/consulting for ruby/rails jobs because the money being paid was way above that for other similar level devs. It was pure hype, and to be fair to everyone who did this, the saw the writing on the wall and rode the wave. I even knew one SEO Exec who switched to ruby/rails contract dev work; if that isn't a warning sign, I don't know what is! Just to note, I'm a PHP dev who works in SEO, and have done for years, during the great SEO boom, so I know bad code and I know snake oil salesmen. But I think in about 12/18 months time, once all the charlatans have moved on, the ruby/rails devs left will be experienced, battle hardend legacy devs, and the respect will begin., much like the SEO industry now.
leereeves 12y ago
Most executives at non-webdev companies don't know anything about Rails, except what their staff and consultants tell them. If a fair number of those executives learn too late about the technical limitations of Rails, they probably do feel burned, and word gets around.
functionalfoo 12y ago
Burnt in the sense that businesses hired people who claimed to have solid development experience, who claimed they could build robust maintainable systems, who claimed they could solve real business problems, who then turned out to be a lot less spectacular or solid than first thought, who believed the solution to every problem or design phase was to simply add more gems into the mix, who changed the whole state of the codebase because one luminary in the ruby world posted a blog article about how the hot thing on that day was to use pattern x instead of pattern y for designing your models vs controllers. Most businesses are technology agnostic - they don't care what we use, if, if we deliver robust technically sound solutions. But when they trust developers, who fail to deliver, they mark the technology choice as well, to avoid getting similar problems in the future.

tdumitrescu 12y ago

I don't think it's about performance. It's about the glut of inexperienced, underskilled Ruby devs landing seemingly simple gigs where they patch together unmaintainable Rails spaghetti - ultimately saddling clients/employers with a heap of technical debt and hobbling future devs who come to these projects.

sanderjd 12y ago
This is a case of getting what you're willing to pay for. Great work is expensive because it takes a lot of experience to do, and there are a lot of opportunities for those with a lot of experience. But if you're willing to sacrifice the "great work" part, there are plenty of people out there with less experience doing (potentially) less great work for less cost. Everybody would like above market work for below market cost, but it doesn't tend to work that way.
- jalfresi 12y ago
  I see what you're getting at but when Ruby/Rails was all new and shiny a couple of years back I knew an awful lot os junior/inexperienced devs who quite permanent jobs to go freelance/consulting for ruby/rails jobs because the money being paid was way above that for other similar level devs. It was pure hype, and to be fair to everyone who did this, the saw the writing on the wall and rode the wave. I even knew one SEO Exec who switched to ruby/rails contract dev work; if that isn't a warning sign, I don't know what is! Just to note, I'm a PHP dev who works in SEO, and have done for years, during the great SEO boom, so I know bad code and I know snake oil salesmen. But I think in about 12/18 months time, once all the charlatans have moved on, the ruby/rails devs left will be experienced, battle hardend legacy devs, and the respect will begin., much like the SEO industry now.

leereeves 12y ago

Most executives at non-webdev companies don't know anything about Rails, except what their staff and consultants tell them. If a fair number of those executives learn too late about the technical limitations of Rails, they probably do feel burned, and word gets around.

functionalfoo 12y ago

Burnt in the sense that businesses hired people who claimed to have solid development experience, who claimed they could build robust maintainable systems, who claimed they could solve real business problems, who then turned out to be a lot less spectacular or solid than first thought, who believed the solution to every problem or design phase was to simply add more gems into the mix, who changed the whole state of the codebase because one luminary in the ruby world posted a blog article about how the hot thing on that day was to use pattern x instead of pattern y for designing your models vs controllers. Most businesses are technology agnostic - they don't care what we use, if, if we deliver robust technically sound solutions. But when they trust developers, who fail to deliver, they mark the technology choice as well, to avoid getting similar problems in the future.