Home > Development > Converting Java developers

Converting Java developers

I’m the resident “JRuby guy” most everywhere I go.  Coupling a lack of Ruby-loving attendees and my predilection to get into “conversations” about the relative merits of various programming environments, the title all to often fits.  Guilty as charged your honor.  So, tonight I was asked an interesting question:

How do you convince a Java developer to use Ruby?

My answer:

You don’t.

My second answer:

You wait until the person is unhappy with what they have and then you be there as a resource to them when they go looking for a better solution.

Basically, the long version of “it depends”.  The particular instance I was being asked about was a fairly large team (30) using Spring MVC.  They all knew Java of course and one senior member of the team was trying to convince the team lead (also at the meeting) that JRuby or an equivalent would be a good way forward.  This team lead was pretty skeptical, (surprisingly so given my previous interactions with him), and wanted to know what this extra layer of abstraction was buying him.  I replied that it vary well may not buy him anything.  I think this was an answer he definitely did not expect and I also think it was exactly the “right” answer.

I went on to elaborate on my “it depends” answer, probing to find out where their bottlenecks were.  Was it hardware, delivery time, team size?  The first answer was performance, “it has to run fast” he said.  Some more back and forth and it seemed performance was important but not constraining in the way it would be on a single desktop or an embedded device.  No, this was a web app, and he eventually conceded that three new developers is probably a lot more expensive than three more servers.  I brought up the fact that they were using Spring instead of just straight Servlets.  Why?  That’s potentially a ton of layers of logic to go through.  Clearly there was a value to the tradeoff and my point was soon made.  After about 15 minutes of questions from the team lead he seemed quite satisfied and stated that he felt much better about the prospect of moving to something like JRuby now after talking to me.  He even said that he would like me to come speak to his team and field their questions about JRuby.

This was not the first time this has happened to me and I hope it won’t be the last.

So, my takeaway for all Ruby advocates:

  1. The hard sell of Rails may have worked to get lots of attention for Rails/Ruby and for that I thank everyone who helped make Rails a success, but it won’t pull everyone across.
  2. After 2+ years of hype, hype, hype, a realistic explanation of what Ruby can and can’t do, what it is good and not so good for is a welcome thing to many skeptics.
  3. Even the doubtful can be converted if given the proper care and attention.  Be passionate, be sincere and be honest and that will come across with far more weight than your expose on how higher order functions are the solution to all of programming’s ills.
  4. JRuby is the magic bullet that makes a lot of people even capible of conemplating a migration over to Ruby-land.  It integrates with Java flawlessley and it’s the fastest Ruby available so that helps a whole lot for the peformance-minded crowd.
Advertisements
Categories: Development Tags: , ,
  1. September 11, 2008 at 4:40 am

    So basically you are saying that instead of doing a performance test you looked at a picture of a stack trace and decided that the Spring stack would be slower than JRuby.

    Wow, I wish decisions around where I work were that easy 😉

  2. dkoontz
    September 11, 2008 at 11:51 am

    The stack trace had nothing to do with an argument about performance. I used the stack trace simply to illustrate the idea that we have massive amounts of abstraction layers going on in almost all projects (including the use of something like a virtual machine) and those abstractions are typically considered a reasonable tradeoff for the advantages they confer. JRuby is the same thing, it’s a tradeoff and it may or may not be the right one for a particular project. All layers of abstraction introduce some sort of “performance” hit, simply because there is another layer of indirection (barring VM magic that can inline/loop unroll/etc.). The question becomes, is your abstraction layer a net win or a net loss?

    Or did someone forget their sarcasm tags this morning?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: