Ruby and the myth of developer productivity

Recently I was in a conference room with the CIO of a large corporation and representatives from a vendor that provides a somewhat unrelated product. The corporation's software is mainly in Java. For some reason, in the middle of the discussion, one of the vendor's 20-something presales engineers started pitching that the company rewrite all of its software in Ruby.

The reason? It would result in higher developer productivity.

The proposition that this company would rewrite millions of lines of Java code in Ruby to realise "developer productivity" was absurd. Not surprisingly, the CIO decided he had "another meeting" and excused himself.

This isn't an isolated presales engineer. Productivity benefit has been the pitch for most "new" high-level languages for some time. The Ruby community especially likes to beat this drum.

I think it's time for a new sales pitch for Ruby - and for most high-level languages. Developer productivity is a weak pitch in a multideveloper project, not to mention a ridiculous approach when rewriting code is required, because the costs will long outweigh the benefits. The Ruby community, in particular, needs to outgrow this argument, mainly because Ruby has other, better points in its favour.

Once upon a time, developer productivty was indeed a rational argument for choosing one language over another. When we moved from Assembly to C, for instance - we're talking a major reduction in finger ache, let alone not having to manage the stack. When we moved from C++ to Java, not having to manage memory was huge. But the individual productivity difference from Java to Ruby is comparatively small. Don't get me wrong, Ruby has an edge - which might increase as Java grows more complex and Ruby loses more of its rough edges (as with jRuby) - but it will never be rewrite-the-project-sized margin.

The fact is, issues other than language choice tend to have a greater impact on productivity. On a multideveloper project, team dynamics and software development practices like continuous integration and proper revision control matter more. Communication structures of the team matter more (see Conway's Law). Even a moderate increase in individual developer productivity, which a language change might incur, would be unlikely to make a big impact. Team dynamics and overall project management are that important.

So if developer productivity isn't a good pitch for Ruby, what is? First of all, Ruby has gone mainstream: There are lots of crack developers who have come to prefer Ruby (personally, I like the core Ruby APIs a lot).

Secondly, Ruby has sort of become a first language of the cloud. If I were making the argument that a client should switch from Java to Ruby, I would point out that when cutting-edge PaaS (platform as a service) players offer Java, they couch it as "legacy support." And of course, the fact that Oracle now owns Java and is in itself a risk. Let's face it: Oracle is known for monetising products at the expense of the greater partner ecosystem.

The dirty little secret of our industry is that while we focus on "rapid application development," we spend more time maintaining, debugging, monitoring, and enhancing existing applications. Most of this code is poorly organised and often poorly written. A big reason for that is a general shortage of good developers - and good app dev management.

Rather than obsess over incremental gains from new languages, in most cases you should play to your developers' strongest suit, raise your project management game, and tune your team dynamics. Get those basics right and you'll really raise productivity.