Developer productivity underpins both the cost effectiveness of any enterprise software development operation, and the time it takes to get new products to market. So when a new programming language emerges that claims to make developers around ten times more productive than the staple programming language Java, especially one that is open source and free, CIOs and IT leaders would be well advised to take note.

And while they may not have even heard of Ruby on Rails themselves, the chances are the developers they employ have. Together with other dynamic programming languages such as Python, Ruby has enjoyed a massive surge in popularity in recent years – and that popularity is only predicted to get bigger.

Gartner says there are a million Ruby programmers today, but analyst Mark Driver reckons that by 2013 there will be four million. A June survey by software development research company Evans Data found that Ruby use in North America alone has jumped 40% in the past year, with 14% of developers now using it at least part of the time. In emerging economies, it’s even bigger.

Developers like Ruby because it makes them more productive, and when they use it in conjunction with the Rails web development framework, they can piece together applications in minutes. Huge sites such as yellowpages.com and Twitter are written in Ruby, and web development chiefs at sites such as Oakley.com and Simonandschuster.com have taken the decision to ship their legacy PHP and Java code over to Ruby on Rails, citing time to market and flexibility as the critical advantages.

“The positive thing is you’ll have very motivated staff and you can do really cool stuff. On the downside, these people are much in demand, so they could move on."

But there have been questions about the performance and scalability of Ruby on Rails – and as with any new platform, the biggest issue early adopters face is finding the right skills. The key question is: is Ruby enterprise ready?

An object-oriented (OO) programming language that borrows some of the best bits from OO languages such as Smalltalk, Ruby was developed in Japan in the 1990s. Adoption only really exploded, however, following the release of the Ruby on Rails framework in 2003 by David Heinemeier Hansson, written as he was developing the popular Basecamp project management tool at his company 37Signals (see below).

An open source framework which exploits Ruby’s ability to modify itself, Rails helps plug the different components of an application together, and is maintained by a close-knit open source community. Since then, Ruby has been ahead of the adoption curve of other dynamic languages.

The TIOBE programming community index, which monitors engineers, courses and third-party vendors has seen Ruby jump from 25h place in the programming language league table in 206 to 10th place today. Koders.com, a repository and search engine for open source code, ranks Ruby as its fourth most requested language after Java, C/C+ and C#, and says the number of Ruby searches submitted have increased more than 20 times since 2004.

Why developers love Ruby

Entering the Ruby community is like being admitted to a very exclusive fan club. “Rails developers are a passionate bunch. It’s almost like a religion to them,” says Ken Loh, Web director at sunglasses-to-goggles sportswear firm Oakley, which began re-architecting its website from PHP to Rails in 2007.

“That’s a good thing and a bad thing. Sometimes it will not do everything – and you need to balance the enthusiasm on the management side so you don’t just do everything the Rails way for the sake of it.” Loh admits that back in 2007, adopting Ruby was a considered risk.

“When the developers brought Rails to me and explained the concept, it seemed to be just what I wanted. It was unknown at the time and very new but Oakley is a company that is willing to take a risk.”

Once they do try it, many developers enjoy the flexibility and room for experimentation that Ruby allows. One says: “In Java because it’s statically typed, many expectations are set in stone. In Ruby, you can be more vague – you can even add to the behaviour of objects at runtime. This gives you the advantage of being able to do interesting and surprising things.”

Unlike the popular scripting language PHP, Ruby was not specifically created for developing web applications, but Rails takes it into that dimension. Because it’s an interpreted language, compiled and executed at runtime rather than being pre- compiled like C, it’s portable, and able to run on any platform – Windows, Unix, Linux or the Mac OS.

Likewise, it’s easy to extend and developers are able to change or insert new bits of code without having to take the whole application off-line and recompile it. Perhaps most significantly, it takes much less code to do something in Ruby than you would have to write in Java to do the same thing, improving agility and time to market. For example, the classic starting point for learning a programming language, printing “Hello World!” on the screen, just requires the instruction: print “Hello World!” In Java, by comparison, that takes about ten lines of relatively complex code.

The concept of testing is also built into Ruby, through test-driven development, which is either a benefit or a drawback depending on who you speak to. Loh describes it as “critical for enterprise software”. Oakley uses the RSpec testing framework which means developers write “unit tests” or test cases before they write the code. The computer then checks that the code fulfils the functions before it is executed. As changes are made to the code, all the tests are run again to make sure the changes haven’t broken something elsewhere in the system.

That can seem a laborious approach – but it means Oakley can make ongoing changes to its site without having to go through a laborious quality assurance process. Its 2007 relaunch took Oakley.com away from being a pure e-commerce site to more of an educational offering, but Loh says it is in a constant state of change. “Every quarter we have added functionality or replaced some legacy systems behind the scenes that are not visible to the outside.”

Ruby in the enterprise

The qualities that make Ruby on Rails appealing to developers are arguably the same traits that cast doubt over its suitability for enterprise applications. Microblogging service Twitter, which has seen explosive growth in the past 18 months, famously questioned Ruby’s performance after reported scalability problems.

Earlier this year Twitter announced it was moving elements of its site to Scala. Alex Payne, one of Twitter’s lead engineers, has said subsequently that his comments were misreported, while Rails author Heinemeier Hansson describes Twitter’s scalability concerns as “95% red herring”, adding: “When people say something doesn’t scale, it’s such a convenient statement because it can be uttered without qualifications and unfortunately still be taken seriously in some places.”

But there’s no getting away from the fact that because they are compiled at run-time, applications written in Ruby are an order of magnitude slower than Java. Ruby advocates point out that there is a pay-off between developer cost and hosting cost – applications might need a bit more hardware in order to run at the same speed, but it could be worth it because they will be built quicker.

Perhaps the biggest issue then with Ruby on Rails is not a technical issue at all – it’s about skills, the difficulty of retraining existing Perl or PHP developers in a new mindset and the problem of finding really good project leads. The developer says: “The positive thing is you’ll have very motivated staff and you can do really cool stuff. On the downside, these people are much in demand, so they could move on.”

Oakley’s Loh also acknowledges this problem. “Rails is all about standards – it’s convention over configuration. So in theory any Rails developer should be able to go into a Rails application and know where to store a file and what to name it,” he says. “In practice, Rails is very new and a lot of developers are not as well versed in the framework as they should be. And there’s not as many really good developers out there. The challenge for us was finding the resources.”

Martin Fowler, renowned OO programming author and chief scientist at IT consultancy ThoughtWorks, has conducted an impartial study of the 41 Ruby projects his company has conducted since 2006. Speaking at a developer conference earlier this year, he noted shorter timeframes and smaller teams on these projects and said he believed Ruby was ready for the enterprise.

But he added this caveat: “Ruby depth is not there, so you need a design expert who is also comfortable with dynamic languages or you’ll screw up.” The risk, he said, came down to an efficiency versus delivery risk: without the right skills you might not be as efficient as you might be, but you’ll still deliver; without the right management, you won’t deliver.