Since I have received several comments and private emails on my first post about bidding projects in Java or Rails, I decided to add some expansion and clarification.

1. People want to know what Java stack we prefer/use. Spring, Hibernate, sometimes Tapestry. We use AspectJ where appropriate.
2. To those who are worried that we are encouraging a price war that is bad for developers: We pay ourselves (and our contractors) better for Rails work than Java work. This is good for everybody: Developers have more fun, make more money, and customers get better products cheaper and faster. I don’t see the problem here.
3. On overcoming resistance to Ruby and Rails because they are new: This is a real issue, and rightly so. If a Rails project is difficult to maintain because Ruby developers are in short supply, then a small development savings up front doesn’t look so great to management. One thing I point out to customers is that maintenance cost is some function of the size and quality of the codebase. A well-written Ruby codebase can be an order of magnitude smaller than a similar codebase in Java.
4. Some people took my “worst case” number (10% advantage for Ruby) and extrapolated that Java could catch up. That extrapolation is going in the wrong direction. The reason that my number is 10% and not 50% is difficulties that sometimes arise due to the relative immaturity of the Ruby/Rails stack. For example, say we bid one project at 20% cheaper with Rails. But, that price includes the hidden cost of building a database driver and some specialized XML processing that does not exist for Ruby (and does for Java). On our next similar project, we’ll be able to deliver 30% cost savings over the Java bid, because the plumbing will already exist for both platforms. And remember, these numbers come after paying developers more.
5. What are applications that are “nowhere near the Rails sweet spot”? This is a complex question, and I’d like to defer answering this one until I have time to do it justice. If somebody posts something in line with my thinking I’ll certainly link it here.
6. A few people have asked questions which amount to “Please give me much more intimate details of exactly how Relevance does business and gains a competitive advantage.” I will politely decline. :-)

OK, we have had plenty of debate and hype about Ruby on Rails. It’s time for IT executives and decision makers to say “Show me the money!” If Ruby on Rails is so fabulous, where are the on-time, under-budget projects?

So, here you go. For the past 18 months, we have been quietly bidding web projects with both Java and Ruby on Rails. The numbers for us, so far, fall out like this:

• For applications in the Rails sweet spot (CRUD+Ajax on the web) our Rails price tends to be 30-50% less than the same bid implemented in Java.
• For applications that are nowhere near the Rails sweet spot (do you know what these are?), our Rails price tends to be only 10% less than the same project implemented in Java
• Applications are completed twice as quickly in Rails.
• When customers want an hourly rate, our hourly rate for Rails work is slightly more than our hourly rate for Java work. However, given that applications are finished 30-50% faster, Ruby/Rails still delivers more per dollar.

This is not to say that the “10x productivity” claims of Rails developers are simply false. There are specific parts of Rails development that are indeed that much faster. But other parts are not, and the 10%-50% above is what we have seen on real projects over the past 18 months.

When 10% is Bigger than 50%

I actually find the 10% number to be the astonishing part of our experience so far. The 50% number sounds better up front, but basically amounts to the same claim that many other people have already made: Rails is extremely productive doing what it was designed to do. The 10% number suggests a much more compelling argument. “Ruby is more productive than Java, period. Even when Java libraries already exist to solve a problem, and you have to roll-your-own in Ruby, Ruby will come out ahead on sizable projects.” It is this 10% edge that prompted me to write the Enterprise Hammer articles.

Given my ideas about why we are more productive in Ruby, I would expect Python or Smalltalk developers to have a similar edge. Anybody out there want to share some numbers?

I am thrilled to announce that Justin and I are teaming up with the Pragmatic Studio guys to produce Pragmatic Studio: Ajax. Join us Feb 9-11, 2006 in Reston, VA for an intense three days learning how to build rich, interactive applications on the web. Details here.

The slides and samples from The Spring Experience talks are now online at: www.codecite.com. Skip to the last slide in either slide deck to get the link for the sample code.

Oh coding brethren, please stop the Monkey Knife Fight over Humane versus Minimalist Interfaces. I have a solution: let’s write a minimalizer for Ruby, and a humanizer for Java. That way, we can all live in harmony, and program in the style of our choosing regardless of which language we use.

Ruby Minimalizer

Here’s the Ruby minimalizer.

def make_minimal(cls, *extraneous_methods)
  extraneous_methods.each {|m| cls.send :undef_method, m}
end

make_minimal Array, :first, :last

Java Humanizer

On to the Java humanizer. Hmm, I’m having a little trouble finding the methods I need here. I’ll just go read the Javadoc for the SDK real quick and see if I find what I need. Thank goodness the Java API is minimalist! I expect to be back in just a few minutes with the answer…

In the early 21st century, computer programmers often used statically typed languages, especially Java. While these languages were suitable for small-scale projects, they were not as well suited for enterprise class systems, where flexibility and adaptability were (and are) primary concerns.

Early attempts to help these languages communicate in distributed systems (CORBA, DCOM, etc.) were not wildly successful. Partially as a result, XML was developed as a connective tissue between systems. Where earlier approaches had failed, XML succeeded beyond expectations. XML became the standard communication language between systems. Surprisingly, XML also became a configuration language within individual systems. (It turned out that even very small applications needed more flexibility than Java alone provided. While programmers still said ‘Java’ what they really did was ‘Java+XML’).

But while XML was a great boon to Java in the short run, it was fatal in the long run. XML decoupled systems enough that enterprises could experiment with a variety of different approaches in different subsystems. Released from the monopoly effects of tightly coupled systems, niche programming languages had room to grow. And grow they did. Older languages such as Smalltalk and Lisp enjoyed a resurgence, along with their newer cousins Python and Ruby. The transition was slow at first, but its momentum was irresistable—thanks to XML.

Wow, today was great. This morning, I got up late, at a bit of breakfast, then went in and gave the “ESBs with Spring and Mule” talk. I was really expecting this to be a niche talk, maybe 10-15 hardcore messaging people with a ton of JMS questions. But there were 50-60 folks in the audience, from all over the place, with tons of insightful questions (only a few of which threw me into panic “I don’t even understand your question” mode). Hats off to the folks here at the show, that was a great talk to be the presenter for.

I followed it up with an intro to Spring MVC, which I also thought might be lightly attended. Again, I was wrong, and the folks that came were really into the topic and had lots of questions after the talk. I love that, because it means that a) people weren’t sleeping, and b) the info was on target. People who aren’t engaged don’t ask questions.

I got the opportunity to sit on the “Expert Panel” after lunch with Rod Johnson, Rob Harrop, Juergen Hoeller, Colin Sampaleanu and Matt Raible. It was a pleasure to be in such august company, even if the microphone seemed glued to Rod’s hand ;-). Somehow, the only time I felt like I had to jump in was when a question came up about what Spring and Rails can learn from each other.

In all, its been a great day so far, and the attendees seem to really be enjoying the show, which is, after all, what it’s all about.

I am in Bal Harbour, FL for the week at The Spring Experience. I’ll be visible running some of the panel discussions, give me a holler if you want to talk about Spring Configuration DSLs.

Last week I posted a teaser for a Ruby-based DSL for Spring configuration. Like so many things, I doubt I will ever have time to carry this through so I am posting the code here. Please run with this if you are interested.

Here’s the approach I used:

• Create RubyBeanFactory as a subclass of XmlBeanFactory.
• Execute the loaded resource, and treat the result as XML. I used Ruby but you could easily plug in some other language.
• Create a helper (spring_config.rb) that defines a simple DSL instead of writing straight Ruby code.
.

• Refactor hard-coded stuff
• Extend the DSL to handle more than just a subset of the Spring config vocabulary

I have this working (in skeleton form). Anybody interested?

bean :id=>:one, :class=>:NamedBean do
  set :name, "first" 
end

bean :id=>:nv, :class=>:NameValueBean do 
  set :name, "nv" 
  set :value, :one, :local
end

bean :id=>"sb-with-string", :class=>:ScoreBean do
  constructor 15
end

In Part 3, I argued that programming languages need to be flexible, and support powerful abstractions. But, there is a concern: Many developers and managers alike fear that more flexible, powerful languages are dangerous. They’re right, but there is a solution: testing and transparency.

To continue with the Enterprise Hammer example: One approach to making the Enterprise Hammer safer is to limit its power and generality. If the hammers can only strike with a certain amount of force, then the hammer cannot accidentally break strong structures. Moreover, if the linkage between the hammers and the frame is deliberately complex, nobody will attach other implements that might damage something.

This safety comes at an extremely high price. The problem with reduced power becomes obvious as soon as you need more power. The problem with reduced generality is more subtle, and therefore even more damaging. When solutions cannot be generalized, work must instead be duplicated. Poor generalization is the leading cause of “code bloat”. And the damage from code bloat is not linear. Poor generalization makes software geometrically more expensive to build and maintain (think “spaghetti code”). Even worse, tools that inhibit generalization inhibit genius—those cross-disciplinary leaps of imagination that move the industry forward.

The “safe language” argument appeals to fear, while the “flexible language” argument appeals to a sense of opportunity and adventure. Both are powerful motivations, so for a long time this argument has been a stalemate. Happily, that period is coming to an end. Two new factors have come into play: automated testing and transparency. Over the next five years they will turn the balance totally in the favor of more flexible languages.

Automated testing turns software on itself. By using code to evaluate that other code functions correctly, we can reach a much higher level of assurance than was ever achieved by the stopgap measure of weakening our tools. Instead of building small, soft hammers, and placing them in a low-powered frame, we build exactly the parts we need. We then test each of the parts individually (unit testing), test aggregates of parts working together (functional testing), and test the entire system (acceptance testing). If we decide to modify the frame, engine, or hammers, we can quickly re-execute our tests and verify that the entire system still works as before.

Transparency comes from open source. Other things being equal, developers who depend on open source will outperform developers who do not. To return to the Enterprise Hammer: Imagine now that frame and engine are covered with an opaque outer shell, to prevent hammer developers from seeing (or tinkering with) the internals of the Enterprise Hammer. This is the closed source world. If the frame and engine are performing perfectly, then the people building and using hammers may not care much. But when problems or questions arise, the shell needs to be removed. There are, of course, halfway measures such as documentation and technical support. But those are never as good as the code itself.

Are testing and transparency recent discoveries? No. What is new is their widespread adoption and acceptance by developers. Something else is new too: developers today understand the basics of OO. When James Gosling designed Java, it gave developers plenty of new stuff to think about. Most developers were new to OO, and had yet to learn inheritance, polymorphism, etc. Developers now understand OO, and understand automated testing. In other words, developers are ready to learn something new, and they have a great safety net (testing) to use along the way.

For evidence that testing and transparency foster good code, take a look at Spring. Spring has succeeded wildly with only a fraction of the investment (time and $) that has gone into closed-source J2EE stacks. But doesn’t Spring’s success argue in favor of Java, not more flexible languages? Stay tuned for the next installment.