Success Criteria

In order to determine in the future whether this experiment has been a success I should set success criteria up front. I gave it some thought, and here’s what I came up with:

1. Interchangeability:

I should be able to use either the Java application or the Ruby one interchangeably, without any apparent impact. I could test this by setting up two servers, working with the same database and other systems, and have clients working with either one. If they don’t notice the change (barring performance issues, that’s another test), then Ruby passes.

This is the most important test – if Ruby passes it means that anything you can do in Java for an enterprise application, you can do in Ruby just as well.

2. Performance:

The Ruby application’s performance should be at least comparable to Java’s. By comparable I mean that if the Java app is twice as fast, that’s still OK. If it’s 10 times as fast, then we got a problem.

3. Productivity:

I expect my Ruby coding to be very rapid. It will have to be – I’ll probably have to invest at least three weeks out of the four weeks per iteration to the Java stuff. That leaves just one week out of four or less for Ruby – or longer hours at the office for me. Now, since I’m going to code in Java first and anything you write the second time takes much less, that doesn’t mean that my Ruby productivity needs to be three times faster than Java; probably just twice as fast.

If that works, then it’s going to be an important selling point for Ruby for the enterprise – good coders don’t come cheap. Twice the productivity is a huge gain.

Also, since I’ve lots of experience with Java and practically none with Ruby, that would mean that you could teach Ruby to your Java developers and get them to be productive with it extremely fast.

4. Elegance:

This is a catchall term for all the stuff I can’t really measure scientifically – code elegance for me means readability, total lines of code, whether or not you need ugly XML files, etc. Obviously, Ruby wins this hands down as far as I’m concerned. I never considered Java to be an elegant language.

So, why is this important? Because these are the things that make coding fun; these are the reasons I’m really conducting this experiment – I want to ditch Java, but I need to supply some proof to the organization that it’s a good idea to do so.

5. Scalability and Maintainability (not testable for now):
Clearly, an enterprise application needs to scale well. It must also be easy to maintain, by generations of programmers. Unfortunately, my little experiment here will test neither.