James McGovern doesn't seem to care for the back and forth treatment his postings generate, so he's come back with this description of my site:
On the contrary, most truths are apt to become familiar and unexciting. No one thrills to the idea that the earth orbits the sun like they used to. But this new blase attitude has not altered the structure of the solar system. Equally, most fiction is surprising and not in the least dull to read, but it remains fiction for all that. The best refutations also tend to draw on facts that are tediously obvious. How better can you refute an opinion than by showing it to be inconsistent with something well-known to be true? Are the below fact tediously obvious when it comes to Ruby on Rails?
Near the middle of that paragraph, he linked the word "fiction" to my site. Well, to each his own - if he can't stand the heat, maybe the kitchen isn't the place for him. Having gotten that off his chest, McGoveren goes on to demonstrate that he's fearful of actually doing his own job via these assertions:
No large analyst firm has spent any time researching Ruby uptake nor have any of their clients asked them to?
Is it the job of analysts to back initiatives, so that the risk for any failures can be spread around? In McGovern's universe, I guess so. Here's a thought: Do your job. Do some research yourself, start a pilot project on a low risk task, and see how it works out. The results of that might actually mean something. Or, you can wait for the next large "IT in 20 years" report from the bozo firm of camp followers.
No Indian outsourcing firm and their bloggers have even indirectly hinted at the fact that they are using it for large enterprise applications?
Umm, duhh. That's because those firms mostly maintain existing applications written over the last 20 years - they aren't creating many new applications. Realizing that might require some actual thinking though.
Even though there are lots of Enterprise Architects who use Ruby outside of work, they never felt it was worth the time to talk about it in any meaningful way at work?
As Chris Petrilli recently noted, this is due to herd behavior and risk aversion. Better to fail the same way as everyone else than to try something different and stick out. The rewards for success apparently matter less than the risks of failure.
If you were to write a mission-critical enterprise application on a Java platform to support 5,000 concurrent users it would be 50X faster than anything the Ruby community could dream of? It would also outscale Ruby by factors?
The wealth of time and effort devoted to this topic is where he gets this from, right? Well, here's the thing - most large enterprise apps spend a lot of time dealing with the database. That part is optimized by doing better table and query design. So Ruby is interpreted; so what? That's simply not going to be relevant for most applications. On the kind of bozo comparisons that McGovern has in mind here, both C and C++ are going to outperform C#, Java, and VB.NET. Does that mean that the enterprise should stick with C, because "clearly" it's faster?
Again, I'll point out the obvious to McGovern: if you actually tried a pilot project, you might learn something. If you stay in the middle of the herd, you won't. I'm sure it seems safer there in the middle; everyone is doing the same thing, and any failures can be balmed over. Then again, the chance of a real outstanding success is also about nil.
I'll skip the rest, since it's getting tiresome to repeat "do your job" over and over. However, this bullet point from McGovern illustrates the pack thinking very well:
Can you point to a single Fortune 200 enterprise whose primary business isn't technology and a single revenue-generating mission-critical system built using Ruby? If you can't, could you at least speculate as to when you think this will happen?
There you go. It's safer in the middle of the herd, where the soothing voices of the shepherds remove all thoughts about anything better.
Update: Chris Petrilli weighs in.