A storm in a teacup was launched last week by an ONLamp.com article making wild claims about Ruby on Rails:

What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible?

I'm not going to be drawn into the Rails vs The World debate. Rails may be wonderful. It may make me significantly more efficient than I would be coding in Webwork. and Java. I've not tried it beyond throwing together a toy application, and I'm going to withhold judgement until I've done something serious with it. But I can categorically say that Rails is not going to make me ten times more efficient. When I encounter this sort of hyperbole, I always find myself returning to the words of Fred Brooks:

But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. -- Fred Brooks, No Silver Bullet

The core of Brooks' argument concerns complexity. Writing software is a complex business, and it essentially comes down to the combination of two types of complexity: Essential complexity is the complexity inherent in the problem being solved. Accidental complexity is the complexity that derives from the environment that the problem is being solved in.

Consider an impossibly perfect tool that reduces accidental complexity to zero. For this magical tool to give you a ten-fold increase in productivity, that would have to mean that you are spending 90% of your time fighting your current tools, and only 10% of your time solving the problem you are coding.

I've been in one or two truly pathological environments where I've felt like this (usually involving EJB 1.1), but you have to do a lot of concerted work applying layer upon layer of antipatterns to get the ratio that high.

This is precisely why demonstrations are to be taken with a grain of salt. Any task that can be performed in a demo must necessarily have an essential complexity close to zero: it's a solved problem before the demo even begins. So if one vendor's demonstration takes a tenth of the time as another vendor's, all that time is accidental complexity.

And even the accidental complexity of a demo is usually of a totally different nature to that you'd encounter on a real project: the kind of complexity that accrues around a task that can be completed in the course of a lecture is vastly different to that which is encountered in a year-long multiple-developer project.

This is why the best kind of products to demo are the zero-configuration products, like Rails, or those IDEs that promise to tie pre-built web services together with the click of two buttons. Configuration is a much more significant overhead for a 45 minute "from scratch" or "here's something I prepared earlier" demo than it is over the lifetime of a real project.

It's like those debates about optimisation. "I just made this loop 10 times faster!" "Great, except we only call that method once a day."

A few years ago, a marketroid visited my then employer to give a demo of a recently re-launched IDE. The demo was very slick, showing how you could throw together an EJB project or a SOAP interface in a few clicks of the mouse.

Then, we started asking about the product's refactoring support, and the answer was "Oh, we don't have that." It was at this point the developers in the audience switched off. The IDE might have made it really easy to set up a web application skeleton or add new actions, but in any reasonably complex task you're going to be spending most of your time dealing with code. Refactoring tools only become necessary when you are iteratively refining your code: something you do constantly as you move towards the solution to the essential challenges of the programming task, but totally irrelevant to a slick, pre-packaged demo.

This isn't to say that improving processes, using more powerful languages and so on can't give you a significant advantage. If something makes you even ten percent more efficient, that's a huge advantage to have over your competition. But if anyone promises to make you ten times more efficient, they're discrediting themselves before they start, which is a disservice to all involved.