They won’t tell the name of the company or give details on the types of applications. Then they claim what seems like unbelievable numbers. If 16% of my apps were on Rails and they were only generating .5% of my support calls I think I’d be inclined to move all my apps to Rails as quickly as possible. That project may very well have the greatest RoI in the history of business. If those numbers hold your support calls would go from 1800 a month to around 37.
Also, what company moves 16% of their apps to an alternate platform and doesn’t bother to hire one single support person for that platform (when they employ 40)?
Could be true. But I have no reason to believe it.
In a big company, who is going to be allowed to take the new technology risk? Senior developers. I imagine that the average dev on their Rails projects is much more competent than on their Java projects. Not becuase it's Rails, but because it's risky.
"as quickly as possible" could be years, even decades. Nothing I've ever done in IT was as difficult as porting existing (ancient) business logic to new technology. It's often easier to just start over.
Are the rails apps simpler because they are just bringing rails in, and want to test it on something simple?
Have the java apps mushroomed into something that customers can't figure out because they're part of an old legacy system?.
Does this even have anything to do with programming? Maybe the people that develop the rails apps have great designer and UI people that make apps that are simpler to use.
Let's not judge on this kind of anecdotal evidence.
Add to that Rails' integration with Prototype+Scriptaculous JS-libraries, enabling you to make easy-to-use drag-and-drop interfaces and so forth. At least for me, those things being easy to do, I tend to build better user interfaces than if I had to put it all together on my own. Simply because it takes less time and effort.
So, it is entirely possible that the Rails apps are more user friendly than the Java apps. I'm not saying this is the whole story, I just wanted to add that to the points you put forth, with which I completely agree.
I do Big Freaking Java Web App development at work. Our core product is built on a Java stack which has been under continuous development for over a decade now. Some parts of it show its age.
We're pretty good at using our internal framework. My colleagues are much better at it than I, since most of them have been working on it for ten years. They estimated 1 ~ 2 man months to implement a particular internal app on the framework. A man month from a senior engineer at my company (the estimator) costs us... hmm... well, I can't tell you, but $10,000 is a nice round number and it isn't very wrong.
I prototyped the internal app in 2 days in Rails, with one day wasted because I was also doing it as my first AppEngine app. I estimate that 2 additional days would get it to substantially higher quality than the current internal app we have running. My fully loaded cost is rather substantially less than $10,000 per month, so I probably could deliver the app for 10% of what it actually cost us.
I can't tell you what the internal app is, but suffice it to say that it is standard CRUD and delivers business value well in excess of either of the development costs. It also uses very little enterprisey stuff.
I got permission for using a few days of company time on that project largely because I have a reputation for bringing certain projects in grossly under budget. My solution is simple: cheat. For example, I was given a stack of Perl code and told to provide documentation for it. The code was well commented and consistently written, but we had NO overarching design docs. (Provider X had subcontracted from Y who acquired Z who... it happens. Enterprise!) We were paid a large fixed bid for the documentation. I wrote a Ruby program to spit it out, complete with graphs describing control flow and web pages with syntax highlighted Perl code. That was approximately 5% my commentary and 95% the output of a Ruby programming which stitched together a one-off Perl parser (thank God for coders who were totally obsessive about their conventions) and an OSS graph producing library, plus Javascript SyntaxHighlighter and an OSS web template. The customer was overjoyed, my bosses pocketed a truly absurd margin (they bid on the assumption I would do it all via sweat of my brow), and I did not have to spend several months of my life reading through hundreds of Perl files with comments written only in Japanese.
That said, while I'd love if we could abandon all of our existing Java code and do nothing but Rails development, we have waaaaaaaaaaaaaay too much invested in our core products to do that. So I nibble around the edges, collect wins where I can, and take stuff I learn from Rails projects and get them incorporated into our core product line. (Example: I hooked the other member of the core team on Prototype, which is now the first and only Javascript library ever supported by our company, and customers who see screens with it incorporated are extraordinarily happy relative to their older, non-interactive screens.)
Likely the Java apps are much more mission critical and likely have been under development for longer and more robust... ergo more moving parts and more to break.
there's a lot to like about Rails - I think its great for intranet type apps, but this story is meaningless. Tell me these apps are mission critical or something, not the company blog and I'll buy in a bit.
It also depends on the number of users, if they only have that little number of rails app, its probably because started using to test the water, and I doubt they used the large applications with a ton of users to begin with. If you have less users, you have less support calls. Applications that are critical or have to adapt to unplanned conditions also get more support calls. I could come up with similar figures for Lotus Notes, Oracle forms or excel spreadsheets based apps.
In other words, the article doesn't really mean anything.
