5 ms·

Do the customers know what Rails is enough to like or dislike it? Or do they like the promises of quick functionality which you translate in to lower costs? I

Do the customers know what Rails is enough to like or dislike it? Or do they like the promises of quick functionality which you translate in to lower costs? If I may also ask, have you run in to an older rails app when someone wanted some fairly minimal additions? Have you been the "next guy?" or do you avoid those projects? Did you migrate it to a newer rails? rewrite it? Or write old rails code? I've run in to a couple of ancient apps that were running untouched for like 4 years, they want to freshen the application, maybe add some features, you have to sell them a major refactor, or you can't touch it, like they depended on some gems that were orphaned. It's not exclusive to Rails, I've seen this with node too, once the application needs to be living and breathing to stay healthy, once you put it on the shelf, it's dying. An express.js 2 to 4 migration is effectively a rewrite, it's not super terrible but it's a chunk of work that isn't adding their new features. I've simply never heard a long term success story with rails or node when it comes to maintenance. It's maybe not a technical thing but it seems like it's the culture of both communities. Blue sky and green field code? It's a blast, fixing up or adding to someone else' existing code? I probably wouldn't touch it. Oddly, I don't feel the same way about a lot of Java stacks though.

mbesto 10y ago
> I've simply never heard a long term success story with rails or node when it comes to maintenance. Basecamp, Shopify, GitHub aren't long term successes? smh...
- cmdkeen 10y ago
  Basecamp went through a massive rewrite, and GitHub went through a long period of (perceived) low pace innovation culminating in "Dear Github". I don't know whether Rails maintenance issues played a part in either of those things. However I do know that YAGNI and tight coupling are traditionally things than come back to haunt you 5+ years later. Front ends may change in that time but the fundamental logic of applications, especially their data structures tends to evolve much slower. Isolating the two can only be a good thing if you're not building a throwaway project.
  - collyw 10y ago
    Everything long term is going to need serious refactoring or a rewrite at some point (or just hire exponentially more developers). I don't think it has anything to do with the language or framework.
    - elbear 10y ago
      But the ease with which you refactor or rewrite does depend on the language or the framework.
      - collyw 10y ago
        Depends if it was written well in the first place. I am maintaining a Django app, and because they have gone for "thin models fat controllers philosophy" (the opposite of Djangos best practices) it is a pain in the arse to modify stuff that should be easy.
        elbear 10y ago
        Ok, maybe the framework doesn't have much influence, but a language with sane types will make refactoring easier. I'm not saying it will make it easy, just easier than other languages.
pmontra 10y ago
I try to answer all your questions. No, those customers only know that Rails is mainstream and so it's a safe choice. If I propose Phoenix to them I bet they will look puzzled and ask me about PHP, Python, Node, Rails, maybe even Java. I'll make a test. I've been the next guy many times. Rails makes that easy because I know where to look. The worst are custom PHP projects because I need to understand the original programmer's way of thinking. It can be a smart architecture (usually it's not) but it's time consuming and inefficient cost-wise. I migrated every single version of Rails. Never total rewrites, no need to do that. I'm maintaining Rails 3, 4 and 5 beta apps right now. The customer with the 3.2 one has very little budget (we atarted and paused the upgrade to 4.2) and it's going to be EOL very soon. We'll see what happens. I was the next guy, that app started in 2011, I got it in 2012. Orphan and incompatible gems happen. They make upgrades more difficult but I always handled them. With node it's an order of magnitude worse because of the much more rapid pace of change. It's the main reason for I would not recommend using Node. Java just costs more to the customer. I use it only when I'm the next guy in a Java project. It's always a pain to work with it. It's like those ten lines would be one if this was Rails and I would have delivered two days ago (small new features). I just don't understand why developers want to inflict that environment to themselves.
- Roboprog 10y ago
  Re: Java environment. Because Java is a huge chunk of the job market (at least in the Sacramento area), not because it's a "language of choice" . Actually, the JVM is a nice thing, even if the Java language is primitive and verbose. Too bad the jFoo alternate language implementations haven't got more traction yet. (jRuby, Jython, Nashorn, et al)
  - pmontra 10y ago
    I can tell you why, speaking about jRuby. Because it takes so long to start and you feel it whenever you run the tests. It gets a little better if you disable the JIT compiler and so... in dev mode, where developers spend all their life, it's not faster than RMI. Because it used to support only the syntax of older versions of Ruby. Basically devs get all the pain of the JVM and none of the gains. Guess what they want to use? A customer of mine asked me how to migrate from jRuby to MRI because devs where having problems. I explained and suggested they could try using MRI in dev and keep jRuby in production. They're a JVM shop. I'll ask them what they decided to do.

mbesto 10y ago

> I've simply never heard a long term success story with rails or node when it comes to maintenance. Basecamp, Shopify, GitHub aren't long term successes? smh...

cmdkeen 10y ago
Basecamp went through a massive rewrite, and GitHub went through a long period of (perceived) low pace innovation culminating in "Dear Github". I don't know whether Rails maintenance issues played a part in either of those things. However I do know that YAGNI and tight coupling are traditionally things than come back to haunt you 5+ years later. Front ends may change in that time but the fundamental logic of applications, especially their data structures tends to evolve much slower. Isolating the two can only be a good thing if you're not building a throwaway project.
- collyw 10y ago
  Everything long term is going to need serious refactoring or a rewrite at some point (or just hire exponentially more developers). I don't think it has anything to do with the language or framework.
  - elbear 10y ago
    But the ease with which you refactor or rewrite does depend on the language or the framework.
    - collyw 10y ago
      Depends if it was written well in the first place. I am maintaining a Django app, and because they have gone for "thin models fat controllers philosophy" (the opposite of Djangos best practices) it is a pain in the arse to modify stuff that should be easy.
      - elbear 10y ago
        Ok, maybe the framework doesn't have much influence, but a language with sane types will make refactoring easier. I'm not saying it will make it easy, just easier than other languages.

pmontra 10y ago

I try to answer all your questions. No, those customers only know that Rails is mainstream and so it's a safe choice. If I propose Phoenix to them I bet they will look puzzled and ask me about PHP, Python, Node, Rails, maybe even Java. I'll make a test. I've been the next guy many times. Rails makes that easy because I know where to look. The worst are custom PHP projects because I need to understand the original programmer's way of thinking. It can be a smart architecture (usually it's not) but it's time consuming and inefficient cost-wise. I migrated every single version of Rails. Never total rewrites, no need to do that. I'm maintaining Rails 3, 4 and 5 beta apps right now. The customer with the 3.2 one has very little budget (we atarted and paused the upgrade to 4.2) and it's going to be EOL very soon. We'll see what happens. I was the next guy, that app started in 2011, I got it in 2012. Orphan and incompatible gems happen. They make upgrades more difficult but I always handled them. With node it's an order of magnitude worse because of the much more rapid pace of change. It's the main reason for I would not recommend using Node. Java just costs more to the customer. I use it only when I'm the next guy in a Java project. It's always a pain to work with it. It's like those ten lines would be one if this was Rails and I would have delivered two days ago (small new features). I just don't understand why developers want to inflict that environment to themselves.

Roboprog 10y ago
Re: Java environment. Because Java is a huge chunk of the job market (at least in the Sacramento area), not because it's a "language of choice" . Actually, the JVM is a nice thing, even if the Java language is primitive and verbose. Too bad the jFoo alternate language implementations haven't got more traction yet. (jRuby, Jython, Nashorn, et al)
- pmontra 10y ago
  I can tell you why, speaking about jRuby. Because it takes so long to start and you feel it whenever you run the tests. It gets a little better if you disable the JIT compiler and so... in dev mode, where developers spend all their life, it's not faster than RMI. Because it used to support only the syntax of older versions of Ruby. Basically devs get all the pain of the JVM and none of the gains. Guess what they want to use? A customer of mine asked me how to migrate from jRuby to MRI because devs where having problems. I explained and suggested they could try using MRI in dev and keep jRuby in production. They're a JVM shop. I'll ask them what they decided to do.