Many developers now know that Ruby on Rails is one of the most important open source projects of our time. The engine behind the growth--intense productivity--is unmatched for frameworks with similar marketshare. While other frameworks boast impressive productivity, no other framework matches the impressive combination of technical innovation and marketshare. The Rails community now contributes an extensive list of plugins (called Gems), books (10 Rails books this year), training, a major conference, and an impressive library of online resources. As Rails makes a splash, even the most conservative companies will begin to consider Ruby.

But so far, this is a revolution has been led by developers. Convincing management takes another kind of persuasion. A manager needs to understand the risks of adopting Ruby, the risks of snubbing mainstream languages like Java--even for one project--and the overall technical landscape of Ruby's capabilities. Frankly, current literature comes up short in this area. This article series, based on From Java to Ruby, will explore the adoption of Ruby in conservative accounts in three areas: pilot projects, understanding risks, and Java/Ruby integration strategies.

The Pilot approach

Ruby is an excellent language. If you want to establish it in a conservative company, implement a pilot progect using the language to solve the right problem in the right context. Let Ruby do the rest. But in order to establish your pilot project, you'll need to first build a case that makes Ruby attractive enough to take the risk. Then, you'll need to add some structure to your pilot strategy. With the resistance inherent in adopting a new language, you want to pick an approach that leaves no room for doubt. Finally, you'll want to lay the political groundwork for success.

So your first step should be establishing a reward, and one compelling enough to overcome the risk of adopting a new language. With Ruby, building your case is easier than you might think.

Finding a compelling reward

When all is said and done, your core advantages will likely revolve around short and long term productivity. Short term productivity deals with the immediate development of your application. Longer term productivity includes the overall maintenance and simplicity of an application. Like most scripting languages, Ruby excels at short term productivity. Unlike the typical scripting language, early indications indicate that Ruby also should excel at longer term issues such as ease of maintenance, simplicity, and extensibility.

Ruby, and the flagship Rails framework, leads to dramatic productivity improvements, often approaching a factor of three to five for certain applications. When you drive your productivity up, you can drive team sizes down, reduce communication costs, and eliminate overhead. Smaller teams can also improve the effectiveness of agile development processes. The multiplicative impact of these kinds of improvements is often understated.

Developers understand the impact of dynamic typing, metaprogramming, domain specific languages, and richer abstractions such as closures and continuations. The Ruby on Rails framework has still more revolutionary features that have not yet been duplicated in Java frameworks. The rapid feedback cycle, baked-in testing, convention over configuration and revolutionary persistence framework are all attractive to Java developers. But you can't rattle off a feature set and expect the impact of your arguments to stick when you're talking to middle management. You need to express those features in terms of productivity.

Longer term benefits exist as well. Reduced configuration, striking simplicity, fewer lines of code, and domain-specific languages typically make Rails applications easier to read. Baked-in testing frameworks simplify unit, functional, and integration tests. The dynamic nature of Ruby makes Rails applications easier to extend. Taken together, these attributes all lend themselves to easier long term maintenance and extension.

Real resistance

A typical manager sees new technologies as huge, neon risk signs, and for good reason. New technologies are inherently risky, and new programming languages take risks to a whole new level, because that decision will last for the lifetime of your application. These troubling risks are persuasive:

• You could pick the wrong problem.
• The language could stagnate, limiting support and enhancements in the future.
• The language could fail to deliver technically.
• The language could lead to long-term problems that are not yet clear.
• You could fail to understand the new technology.

When it all comes down to making the switch from Java to Ruby, you need to reach beyond technical arguments to convince a technical decision maker that Ruby can provide enough business value to overcome the inherent risk of adopting a new language. Your potential reward must overshadow the risk, and your pilot must prove your benefit without a doubt.

Your Pilot Strategy

For From Java to Ruby, I interviewed dozens of developers who have built, or are building production applications in Ruby. I explored pilot strategies that worked to establish Ruby in all different kinds of companies. The goals of a pilot are usually twofold:

• The technical risk axis. Problems with high technical risk help you learn more about the technology you're exploring.
• The political risk axis. You want skeptics to see the technology succeed so you can use it.

Often, these goals are at odds. Selling usually demands less technical risk because you can't sell failure, but higher political risk for visibility. Learning requires slightly more technical risk, because you won't learn a thing by building one more to-do list or blog. And the higher technical risk usually will be in the context of lower political risk.

The first step in planning any successful pilot is planning an effective strategy that balances these goals, and takes advantage of your resources at hand. These strategies come directly from the book. I learned each from a Ruby developer who applied the technique to deliver a working production application.

Trojan Horse

Many technologists try to make a big splash with Ruby, only to get frustrated by politics and risk-averse philosophies. After a few setbacks, they quit. The Trojan Horse tends to work well at companies that move into new technologies very slowly. With this strategy, you work to move Ruby into the system beneath the radar. Here's the general idea:

• You find an unexciting technical problem.
• You quietly solve the problem with Ruby, with as little management visibility as possible.
• You establish a grass-roots campaign to build Ruby evangelists by nurturing culture.

The Trojan horse has low technical risk, and also low political risk. Your goal is to establish some early success with simple problems, build up technical advocates through internal evangelism, and increase in technical and political scope as you accumulate more clout.

Amazon.com is a good example of a company in the early stages of establishing Ruby through the Trojan Horse technique. Steve Yegge, who worked at Amazon.com but is now at Google, is a programming language aficionado who began using Ruby a few years ago. With a number of others, he made sure Ruby was available to developers. Some Ruby visionaries including Dave Thomas (the author and publisher of the most popular Ruby books) and David Heinemeier Hannson (the creator of Rails) have each spoken at Amazon.com, though Ruby is only used there as a scripting language. But the community is growing, and use is expanding.

I was at another company who had an excellent opportunity to implement a Trojan Horse scenario. A European consultancy worked on a Java project, and ran out of money before they were able to build an administration console. Instead of building a console, the customer is managing the database with direct SQL, and is at considerable risk of data integrity problems. We decided that the console would have been trivial to build in Ruby on Rails, but quite demanding for Java. I never found out whether this customer moved forward with Rails.

Objections

With the Trojan Horse scenario, your goal is to eliminate objections by going unnoticed. If you do encounter objections, you'll try to position Ruby as a utility scripting language in the same spirit as Perl, HTML, SQL or XML.

When all is said and done, the Trojan Horse is purely a grass-roots play. You seek to patiently build fertile soil for your grass to grow. By establishing success in small increments, you bet that you'll be able to grow a Ruby project, or the role of Ruby in the enterprise. You will often choose not to go through a formal approval process, or work around such a process based on the low importance of the problem you're solving.

The Race

By far the most interesting scenarios I encountered was the Race scenario. The premise is this:

• You take a demanding problem that's already being solved with Java.
• You spend your contingency budget on building a Ruby project in parallel.
• You build a team that has roughly 20% to 33% of the number of developers on the Java project.
• After a period of time, you pick the project that's farthest along.

With this scenario, the technical risk for the Ruby project is high, but you hope to offset that risk by having a Java project in parallel. The Race scenario makes a very strong case for the productivity of Ruby. The downside is the cost of failure. If you fail, you wind up funding two development efforts for a period of time. But if you succeed, you'll wind up spending much less in the long run. In a real sense, the Ruby project becomes a high-risk focal point with a very high potential payoff, and the parallel Java project becomes expensive insurance. If Here are some of the ways I've heard the race scenario pitched:

• One consultancy built a Ruby project in parallel with a Java project, funding the development effort themselves. They viewed Ruby as strategic, and hoped to use the Race scenario to convince the customer that Ruby on Rails was a viable alternative.
• One developer offered to spend one day developing in Ruby and four days in Java. The manager could choose the best solution after a month or so.
• One consultancy built prototypes in both Java and Ruby to demonstrate the effectiveness of the Ruby solution.

This strategy is a little jarring, but quite useful for convincing managers who are intrigued, but unwilling to pull the trigger. The Race scenario showcases the explosive productivity of Ruby like no other. Out of four race scenarios I encountered, two succeeded, a third is not yet complete, and the fourth project was under budget and ahead of schedule, but lost funding.

The Race scenario is actually less radical than you might expect, especially if the management team has an idea that Ruby is possibly many times as productive. Though the expense is high, this scenario is among the least risky Ruby scenarios. Be careful, though. One of the downsides is that Java remains an option even after your pilot is underway, even if you are successful. You can succeed technically, but still fail to make your case politically. One customer I interviewed completed a successful Ruby pilot, coming in at 1/4 of the cost of the Java projections. The customer loved the "prototype" and asked for it to be completed in Java.

Objections

With the Race scenario, the biggest objection will be cost. Your response to this objection should be unemotional and well reasoned. If you are successful, your overall costs may well be less than a completed Java project. Consider a project where Ruby is four times as productive, such as a classic Rails application. If management decides to ride Rails and scrap the Java side of your project half way through, your total costs would be only 75% of the cost of building the Java project from scratch. If you pulled the trigger on Ruby 25% of the way through the project, the total project would cost only 50% of a total Java effort based on finishing the project with a more productive technology. Surprisingly, your break-even point is at 75% of the way through the project!

The two pilot projects I show here are just two of the approaches I've seen. You can take many other approaches:

• Implement a classic pilot, emphasizing learning over selling.
• Rescue a failing Java project by using small teams with Ruby.
• Put out a low bid for a Java project, betting that you can succeed with less total effort. I've successfully submitted a fixed bid projects for 30% off of the best fixed Java bid, for example.
• Showcase a flagship framework capability such as domain-specific languages or Ajax integration.

Certainly, other effective techniques exist. In some companies, such as those with strong Ruby advocates, Ruby will be a relatively easy sell. In those cases, the role of a pilot changes. You'll want to emphasize learning over selling. In every case, you'll need to keep working to keep the ball rolling.

Capitalizing on success

The absolute key to leveraging a successful pilot to advance your agenda is data. You will want to collect honest, accurate metrics describing your success. You'll usually want to emphasize productivity, but you'll also want to show practical data in areas where there may be major objections:

• Performance data. A common Ruby objection is lack of scalability. This objection is not usually grounded in reality.
• Ramp up. Most managers expect to ramp up Java developers faster than Ruby counterparts, based on the available pool of talent. Rails ramp up is actually very fast.
• Team size. This argument is usually quite compelling. You can do more with less.
• Lines of code. Count total lines, but don't ignore lines of configuration.

This extra effort doesn't take much time, but will make it much easier to capitalize on success. As you work to establish Ruby in a Java environment, keep in mind that you're going to have to show striking improvement. The key is to balance your technical and political goals. You need to decide what will work in your political environment, and how much technical ability your team can deliver. If you want to effectively sell Ruby against Java, use a Ruby pilot to solve the right problem in the right environment. Let the language speak for itself.

About the author

Bruce Tate, founder of RapidRed, LLC is a kayaker, mountain biker, father, author, and Java programmer in Austin, Texas. His five books include "Better, Faster, Lighter Java" and best-selling "Bitter Java". His 17 years of experience include stints at IBM, two failed startups, and his own independent consulting practice called J2Life, LLC.