QCon Wrap-up: Enterprise, Have You Met Ruby?
Posted by Nick Sieger Sun, 23 Nov 2008 08:51:03 GMT
This year’s QCon San Francisco conference was my first time attending, and it was an eye-opener for me for several reasons.
First, the tutorial Ola and I gave on Monday went well, though I was mildly surprised to find that only about 10% of the attendees at our talk had any familiarity with Ruby. This turned out to work just fine as we were able to adjust and fill in a little bit of the back story on both Ruby and Rails. Still, to try to convey a sense of Ruby, Rails, and JRuby all in the span of a 2.5 hour session is a tall order!
Next, I was impressed with the diversity the conference organizers were able to achieve. There were tracks on agile development, cloud computing, REST, DSLs, design and clean code, Ruby, functional programming, real-world architectures, storage rethinking, and more. Tracks were relevant and topical even if the quality of talks was mixed.
The last item relates to my perception that Ruby is not yet seen as a worthwhile tool for enterprise software development. It leaves me with some cause for concern, though it reflects more on the state of the industry rather than on the way Ruby was presented at the conference itself.
What does it mean for Ruby to be “ready for the enterprise”? Does that imply JRuby? Running on the JVM or a Java application server, or even .NET? Reams of XML? Presence of buzzwords, such as JMS, Spring/Hibernate? Or ability to adapt to or leverage legacy code? All of these?
I would argue that Ruby already has everything it needs to be a successful enterprise software development platform, even without using JRuby. Ruby has a mature standard library, a large and ever-growing list of gems and extensions, and a vibrant community. Testing tooling, certainly seen more and more as a critical piece of software development, is also an area where Ruby excels (and brings a strong culture bias toward testing as well). Add JRuby to the mix and the ability to leverage existing infrastructure as well as code, and the picture gets even stronger. Best of all, Ruby the language is a malleable medium perfectly suited for gluing enterprise components together, creating DSLs on top of stable layers and remaining clean enough to be eminently readable and maintainable. Yet behind-the-firewall deployments appear to be elusive; if they do exist, they’re small, isolated apps that work so well, the community doesn’t hear about them. Judging from the low level of participation in Ruby-related talks at QCon, I’m inclined to believe the former.
I was speaking with Jay Fields about this topic on Friday. Jay also noticed that the the Ruby and DSL tracks were sparsely attended. (For that matter, so was the functional programming track.) His observation was that the track content was not marketed and tailored enough toward toward solving enterprise-class problems, or being approachable enough in that regard. We can certainly do better.
Do we have an issue here? Are we, the Ruby community, being too insular and not concerning ourselves enough with bringing Ruby-based solutions to the enterprise? Or perhaps businesses are waiting for more organizations that can provide services, support and indemnification? Does there need to be a Ruby, Inc. (or even a JRuby, Inc.) that looks at common enterprise problems and devises best-of-breed solutions (a sort of SpringSource for Ruby) for things like enterprise integration, security and identity, reporting, business workflow, decision support, etc. ad infinitum? Ruby should be able to do all of those while bringing the increased agility and productivity that we’ve all experienced.
I seem to have raised more questions than I am able to answer at this time. Of course, the obvious answer is that adoption of Ruby will just need more time, but I’m not willing to accept that as the only reason. I’d love to hear your opinions on contributing factors and what can be done to mitigate them. It seems like there’s a huge opportunity waiting to be tapped to help make Ruby more enterprise-worthy.
And yet, despite the less-than-stellar turnout for Ruby at QCon among conference attendees, I still had a great week, and would go back again. QCon is a fun and well-organized event overall, and I got the impression that the folks present were on the leading edge of “the enterprise”, which is exactly the people we need to engage to bring about growth in adoption of Ruby. For that reason, I hope we can kick it up a notch and take another shot at pimping Ruby at the next one. Maybe I’ll see you there!
At the risk of sounding cynical, I still hold to the belief that Ruby as well as most (perhaps all) functional programming languages are too much for the enterprise.
Why?
Because neither Ruby nor most functional languages are useful in the hands of mediocre developers.
Just to offer a little background, I’ve spent most of my twelve professional years as a programmer in what nominally goes for “the enterprise”. Speaking from that experience, the enterprise has its share of talented programmers; however, as a rule, it caters to mediocrity. I’m talking about the kind of mediocrity where raising simple notions of encapsulation and polymorphism frequently result in blank stares on the parts of these developers.
CTOs in the enterprise are frequently choosing technologies that serve the lowest common denominator in an attempt to eek productivity out of the largest number of people. This is because the enterprise has a very low bus-tolerance (the probability that any one person will be hit by one, that is).
As such, this is not to say that Ruby programmers are better just because they use Ruby. However, to be productive with Ruby, it is firmly my belief that one must be a better programmer than the generally mediocre level offered within the enterprise.
That said, as for the attendance issue, QCon always struck me as a high-level almost touchy-feely conference. I would expect low-level nuts-and-bolts topics, such as Ruby, to easily become lost in the weeds there. Then again, hindsight is 20-20.
Ruby (and Rails) doe exist in some large Enterprises, although of course the CIO may not know about it and it was a bottom-up development effort.
But it has nothing to do with mediocre developers (of which I proudly consider myself one) it is more about which IT environments are conducive to use of Open Source. Despite all the sex appeal of web applications, Ruby (just like Python) works great as a Perl replacement for system administration.
It is ready- and it is being adopted for web applications on the intranet. It’s so much easier than building a comparable Java web application that no one has to make a big deal of it.
It doesn’t get as much press and attention from the likes of Gartner and Forrester because there isn’t anyone paying the analysts to look at it.
I think Evan’s comment has it completely backwards. All of the less skilled developers in our organization are doing vastly better with Rails than the Java web apps with Struts plus Spring plus Hibernate that have more than 10x the amount of code and configuration from the apps that are replacing them. We are in process of moving many of our largest applications to that framework, including one Perl CGI app that had two failed replacement efforts in Java technologies.
The biggest problem I see is that there isn’t a big company behind it, “backing it” in enterprise-speak. It took a RedHat to really get Linux into the enterprise. If something is wrong with the framework, people want to be able to pay for 24x7 support and getting bugs fixed. This could be a great revenue stream for Sun as the purveyor of Enterprise JRuby on Rails support contracts- and Sun could use a new revenue stream. Sun needs to advertise it, promote it to the analysts, and get a few more people on Nick’s team.
Frankly, the biggest problem we have in the enterprise is people fighting against custom coding in general. They want to buy things like Lombardi TeamWorks to update a simple status field in what would be a simple Rails app. The costs associated with Java development have poisoned the well for all custom development efforts. Rails needs to be marketed as a ready to go, customizable solution to various problems, in the manner of Rails Kits. We need to revise the data behind the build vs. buy equation.
Great observations all around. I have had the same concern you do, and wondered why Ruby wasn’t being considered more often for use in large projects and large enterprises. And I think I have some reasons for what we’ve seen at these sorts of conferences:
First off, I also see low attendance for Ruby talks at mixed-subject conferences. And while this is a cause for concern (because we’re obviously not selling Ruby in such a way that attracts non-Rubyists), I’ve also noticed that hardly any Rubyists I know attend these conferences. So perhaps what we need to be doing at such conferences is focusing our talks and selling points entirely toward non-Rubyists. Anyone who starts using Ruby seems to depart these conferences en masse.
Second, the enterprise question. I think it’s no secret that there’s concern for the standard implementations of Ruby these days. They’re not moving fast enough, and in many cases not addressing the concerns of “enterprise” users at all. I think what’s needed is to continue pushing Ruby to solve all of those issues as quickly as possible, and convince other Rubyists to help out. It will encourage faster progress in the C impls, and it will show that if you really need a lot of those enterprisey features, JRuby is very likely to have what you need.
Ruby is at a crossroads right now, and needs to grow beyond the young rebel crowd into large-scale businesses. And I think JRuby’s really the way that will happen.
Nick -
I’ve been trying to get Ruby into the enterprise for two full years now. It just won’t happen.
I’ll be cynical with Evan. The basic reasons I’ve seen are non-reasons:
All told, I think it is just simple resistance to change. Progress will be made when the current guard dies or moves on. There are too many decision makers that simply have no interest in understanding, nor see any direct benefit to embracing, the Ruby or JRuby world.
Peter
Great observations, Nick. After working in one of the largest “Enterprise” software vendor for over 11 years, I can cite some reasons why Ruby/Rails hasn’t taken off:
Most CIO/CTO decisions are driven by what the software vendors are pitching. And right now, there’s not one large enterprise software vendor that is pitching a Ruby stack... or for that matter a JRuby stack (huge opportunity for companies like Sun, Oracle, and IBM).
Tooling doesn’t exist (outside of NetBeans 6.x) to help mediocre programmers to be productive. I know, it sounds like an oxymoron. The problem is that most enterprises are riddled with mediocre programmers. Most large enterprise software vendors in the tooling business are so focused on dumbing down IDEs so that these mediocre programmers can focus on “drag and drop intefaces to manage business processes” (bullshit). I think @evan (above) is right about this.
CIOs/CTOs aren’t going to utilize technology that doesn’t have a company behind it to hold responsible. Why do you think so many companies pay so much money on maintenance fees? It’s sad really. There are few organizations in this world that have really understood and appreciated the role of open source.
In the end, I think the biggest reason why Ruby hasn’t taken off faster than we’ve wanted (in the enterprise) is because of the large software vendors (like our employers). It’s difficult to change or redirect the focus of a large software vendor -- I’ve been doing it for the past several years... and I’m seeing some change and acceptance, but it’s going to take a while. There are too many existing customers running on existing technology that’s in conflict with a change of strategy. Unfortunately, it’s not like the change from COBOL to Java... Java to Ruby (or even JRuby) is a lot harder proposition.
Rich
Rich: I like your breakdown better than mine. ;-)
Seriously, though, I agree that a lack of a major commercial entity backing Ruby, poor tool support (to assist mediocre developers), and a lack of marketing to CIO/CTO-types is what keeps it out of the mainstream.
However, Reg Brethwaite (sp?) made a great remark at RubyFringe. I paraphrase, “If you need tool support then something must be broken in the language.” That said, there are opportunities to improve.
I think the real issue is what Matt points out:
On the occasions where I’ve done rails consulting with an enterprise outfit, that’s always what the equation is. Do we build something, or buy this $50M generic app assembly framework. Gartner and friends tell you that the genericness will work, when everyone knows it will build a useless, ugly application.
I don’t feel we need to advertise ourselves as pluggable app components though, the real solution is to attack the panacea of reusable or generic software.
As Evan, risking being a little bit too cynical, I will agree that the “Enterprisey” (with capital “E”) will still take a long time to joing the Dynamic Programming bandwagon.
For one, the vast majority of them has yet to realize the Agile philosophy. I’ve left the Enterprisey market precisely for the fact that dealing with RFPs, with humongous Big Design Up Front bibles, with “business” analysts and so on are very frustrating.
Those kind of companies want “well established” platforms, the kind that change very little, are very bureacratic, very “controllable”, with armies of cheap developers available, with an established consulting playground, training support, several layers of certification levels (so they can level the hourly rates).
Ruby, Functional Programming, DSLs, REST and so forth are well suited for companies (small and large) that have real concerns about software quality, high level of delivery, pragmatic programmers, future-proof thinking. Most enterprises consider IT as just another cost center, so they buy into whatever the major consulting firms are selling, whatever black boxes sounds better in their portfolio.
Maybe in a time of financial crisis, they may rethink a little bit better on better spending their dollars, so Agile philosophy, productive tools such as dynamic languages have more chance of being adopted.
On the other hand, many of us think that this is not necessary, as the smart companies are already adopting such things. So I think that we have smart things for smart companies, and bureacratic and not so good things for “E”nterpriseys.
Thanks for all the thoughtful answers. Some responses to a couple of points:
To Evan and those lamenting the “mediocre” programmers, I say, be careful. Dismissing the average programmer and saying they can’t handle Ruby is like running for political office and telling the under-educated class that they can’t have any assistance for college tuition. We’re in a position of leadership, guys. These are the kinds of people we want to rescue and make their job more interesting and fun! Let’s not belittle them, but give them the tools they need to discover and help them spur adoption.
AkitaOnRails, I think you nailed it. If enterprises refuse to embrace dynamic languages and agile processes, they do at their own peril. Let those companies die under their own weight of heavy tools, bloated code, and fragile processes! Instead, let’s target those businesses that are prescient enough to realize that the health of their company depends on being more agile, and Ruby is part of the antidote!
By the way, Nick, I don’t think I sent you the podcast we recorded, here it goes.
Cheers :-)
What would be awesome would be a Sharepoint competitor, built on JRuby on Rails and marketed by a large vendor. We tried to use the Sun Java Portal product, it was a disaster. Enterprise customers love Sharepoint. It’s horrible from an integration perspective, but they love it because you can set it up without a developer- even though the developer dreads the moment when she has to come in and start writing custom web parts for the beast. I just lost a medium sized custom development opportunity to Sharepoint- that’s the speed of delivery we have to achieve these days. I am working on building my own portal now so that I can present it with my next similar bid.
I really don’t believe anything about enterprises and dynamic languages being a real issue. We have tons of SQL code. We have lots of JavaScript code. We have Perl all over the place.
There is a training and certification thing that is a little lacking. Sun does offer a Perl class. If they offered a JRuby on Rails training and certification...it could help enterprises have the confidence to hire those first Ruby developers they need to get going in the right direction.