I am an avid reader of Joel on Software. I read the book and actively follow the blog. I admire Joel, his career and his willingness to speak his mind. I don’t always agree with Joel, but I always respect his opinion. He has a fundamental way of looking at seemingly complex things that can tend to oversimplify the issues, but they can also bring about understanding and foster discussion.
Apparently, his Language Wars post from last week upset DHH, a self-described “Emo Programmer,” because Joel claims that Ruby on Rails isn’t “Enterprisey” enough. David doesn’t seem to agree and claimed that Joel’s post was a textbook example of FUD in action. If this turns into Adam Curry v. Dave Winer, it could be interesting to watch.
Now I am probably out of line in declaring this a flame war when Joel has yet to provide a direct response to DHH. But DHH is doing his best to shake the trees. See Exhibit A, Two posts and two updates to the second post all in the course of one day.
DHH missed the point of Joel’s post, which was to say that for enterprise applications (read: internal) there are only a limited slate of options (.NET, Java, PHP and 1/2 Python). I think he’s right. And don’t get me wrong… I really like Rails. I love the flexibility; I love the simplicity. I love the “fight the power” attitude that comes packaged with the bits. I have used it a bit on the side and will continue to do so when free time lands in my lap. I’ve even considered repurposing this blog in Rails to add some AJAX-y goodness.
But Joel’s point goes beyond the classic “My programming language is cooler than yours” mentality that populates playgrounds and UNIX circles. It’s not about cool or fun or exciting. It’s about what the enterprise can tolerate and is ready for. When we make architectural decisions at Compassion, we always consider context. Context is king. It dictates what you can afford to do with what you’ve been given. Context also brings in factors like how risk tolerant your customers are and what your Machine Service Bureau (MSB) or support group is willing to maintain.
37Signals is changing the world with their software, and that’s not an understatement. Do I want to use Rails in house at Compassion tomorrow? Of course, I’d love to give it a spin on something internal. Is that a wise decision based on my current context? Not for another year or two, which is exactly what Joel meant. When the Enterprise is the customer, that’s a reality.
All that being said, Joel is missing something here as well. Rails may not be in Joel’s short list now, but I’d be willing to bet it will be before Python makes the skip to a full option. Why? Because Rails in the poster child for agility and getting things done with software. It doesn’t matter that Python has some of those flavors. Ruby on Rails is a term executives are hearing. Rails is also the poster child for AJAX and when AJAX crosses into the enterprise, so will Rails.
In addition to that, the ubiquity of SOA in the enterprise may make all of this moot eventually anyway. Think about it: If my enterprise has a fully-loaded SOA with all the ESB bells and whistles, why couldn’t development team A create a rails application that used services provided by Infrastructure team B? As long as team A’s app can create and consume the right messages (and don’t even assume SOAP… a good ESB can translate REST to SOAP and back again) who cares what stack team A uses (assuming team A will be dogfooding said app)?
In my opinion, all of this is just smoke and wasted bits when we’re in the middle of a technology shift that is enabling these things to play together. So if personal preference becomes the rule of the day (which Microsoft certainly supports by creating languages in .NET that all compile to the same MSIL code) when will these silly schoolyard squabbles stop?
