In the recent, rather entertaining discussion between James McGovern and the rest of the world, about Ruby and Rails being enterprise-ready or not, a lot of emphasis was placed on the speed of development that Ruby and Rails may offer. Anne Zelenka correctly stated that speed of development isn’t all that important in an enterprise environment.
In a way it is sad, but big enterprises, large corporations, might not care much whether an application could be developed with Rails in half the time it would take with Java. Development (I’m including design here) is only a small piece of the entire implementation of an application. There’s functional testing to be done, training of end-users as well as support staff, setting up and maintaining the technical infrastructure for development, test, acceptance and production environments, data conversion, and overhead costs like project management, meetings, planning, the works. Things you can happily do without (more or less) if you’re a web startup, but not so for your average enterprise. (I’m not saying an enterprise couldn’t cut back on them, but most just don’t or won’t — it seems to be a given when you’re entering the enterprise world). And then of course there is application maintenance. Long ago I learned that, as a rule of thumb, application maintenance costs 20% of application development — yearly. That’s 20% of the costs of design, development and testing. Which means that, if you keep developing new applications, your yearly planning slowly fills up with maintenance work.
Instead of just focussing on the amount of development time you might save on, why not focus more on the reasons why development time can be saved on? For example, one of the reasons developing in Rails is so much faster, is the principle of ‘convention over configuration’. I think that might hold some attraction, as it is something that many enterprises are already trying to achieve, for instance with software factories: standards based coding. As a by-product of this, you need less code for your application, which also means less code to maintain. Another example is the shorter build cycle (at my current Java project, the “record” for longest build time stands at 1.2Ms). And how about prototyping? You might actually sit down with an end user and prototype view, model and controller in a Rails application. I’ve never seen that done properly in a Java environment. Prototyping often results in better user acceptance. Or test driven development, which in Rails is not an afterthought as it is in Java. TDD can prevent many unnecessary bugs, so also means less maintenance. (At the moment I am on a project where unit tests “are not needed because all code is generated with OptimalJ.” Yeah right.)
If Ruby and Rails can solve problems that enterprises currently have in their development environment, and save time and money in the process, they could become more interesting for bigger companies.
Of course, there are also reasons why enterprises may not want to use Ruby and Rails — but that’s for another post. Or maybe I should leave that to James McGovern.
Disclaimer: I am neither an enterprise architect, nor a thought leader on that subject. My opinions are based on my work for Dutch enterprises, which may not be comparable to U.S. enterprises. And I’m talking primarily about developing web applications, where Rails excels.
2006-03-27. 8 responses.