March 11, 2005
Catching a Silver Bullet
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.
Posted to nerd at March 11, 2005 01:26 AMProductivity Optimization: Charles Miller catches a silver bullet. I agree one hundred percent: No single technology is going to make you 10 times more productive, not even Rails (no matter how beautiful it is). Still, I really, really like Ruby and Rails — I hope to find ...
From: Stefan Tilkov's Random Stuff at March 13, 2005 07:21 AMRequired Reading: "No Silver Bullet": Via Charles Miller, a link to Fred Brooks's classic essay, "No Silver Bullet". (You can also get it at the IEEE Computer Society, here.) As a small advertisement, here's a quote: "I believe the hard part of building software to be the spec...
From: pbblog at March 13, 2005 10:43 AMIf you think it's silly when an OnLamp article makes these claims, check out the ex-Oracle CTO pitching 10x improvement not just on development, but:
* Ten times faster to complete projects
* Ten times better quality in new systems
* Ten times the power of features and functions
http://seminar.tenfold.com/
People -buy- this stuff?
Posted by: Jeremy Dunck at March 11, 2005 01:57 AM (#link)In fact, using the next generation EnterpriseTenFoldOnRails will take you back in time.
Now, no matter how you look at it, that's real productivity gain right there.
Posted by: PA at March 11, 2005 03:12 AM (#link)Here, here Charles. I'm in the process of getting under the covers of Rails over at my blog too. As I have said, there are some nice concepts about rails but 10x productive is all hype.
Posted by: Patrick Peak at March 11, 2005 03:29 AM (#link)nice post, but not much fresh flesh, so let me take a novel point of view: have you considered that a large part of today web stuff is actually little more than a demo app[1]?
Just consider how full the www is of weblogish things, wikish things, kind-of-blogs-sometimes-called-CMS-or-portal-but-really-phpnuke-clones, ecommerce sites wich are built by hacking stuff like OSCommerce, forums wich do not even provide tree view, and so on.
Rails would suck for EAI[2], I bet my first child, and so would php.
But most of the time web thingies are little more, and sometimes less, than a demo app, and this makes me feel cold and rough inside.
[1] actually today I searched for 'wasp' on google, out of one page of results, there were just two I'd need more than 10 minutes to put togheter, excluding design stuff.
[2]at least in the near future
Posted by: verbat at March 11, 2005 08:46 AM (#link)Excellent post Charles, I'm a java developer and rails contributor and these 'x times more effective' posts bug me just as much coming from rails supporters as they do from IBM and the other 'silver bullet' vendors about their magic beans.
The response from some java developers though has been just as bad (as I wrote earlier http://www.koziarski.net/archives/2005/02/22/java-developers-and-rails).">http://www.koziarski.net/archives/2005/02/22/java-developers-and-rails ).
Posted by: Michael Koziarski at March 11, 2005 09:59 AM (#link)While a language or framework doesn't change how quickly you think, it may change what you have to think about, and that can make a difference.
Spending most of your timing thinking how to implement a solution (databases, style sheets, xml, java syntax, beans, ant-file maintenance, server configuration, etc.) versus another environment where you're spending most of your time thinking about the problem to be solved could result in productivity differences of 10 to 1, possibly even in situations beyond the toy-problem domain.
I agree, Ruby on Rails is not ten times faster. I've only experienced two-three times faster development speeds. Ok, when updating or adding functionality it might even go as high as four times faster than what I've experienced with other platforms. But ten? No, that's stretching it.
Posted by: Tomas Jogin at March 16, 2005 08:08 PM (#link)While I don't really disagree with your overall point, there is a fallacy in the No Silver Bullet argument. Complexity is a continuum with no upside. The best you can hope for is zero badness. Tools can provide goodness, not merely reduce badness.
If you can specify a user interface and a database schema, and your tool can fill in everything in between, that's going to increase productivity. This reduces your essential complexity. Admittedly, if you MUST dig in to the generated code, the accidental complexity may be quite high, but my point is that it's not just a matter of reducing complexity. The right tool can increase productivity, which is a positive, in contrast to decreasing complexity, which is simply a non-negative.
I believe the order-of-magnitude increase in productivity will come from code generation, and Rails looks like a step in that direction, in spite of the hype.
Posted by: Lee Grey at August 2, 2005 06:54 AM (#link)I just posted a page on my blog about all the Rails silver bullet hype too.
http://compoundthinking.blogspot.com/2005/10/silver-bullet-on-rails.html
I have a little bit different take on it. Rails --BY ITSELF-- can't make you 10x more productive, but rails along with small teams, unit tests, iterative development, and simpler refactoring can.
It's not just the technology, but also the improved processes that seem natural to the Rails world, and unnatural to a lot of the Java world. Rails seems likely to require 1/3 the number of lines as the same app in java, so a fairer estimate would be that Rails has the potential to make a programmer 3x faster than they would be in Java.
Posted by: Mark Ramm at October 20, 2005 05:19 AM (#link)