InfoQ

News

Ruby and the hype cycle

Posted by Werner Schuster on Oct 08, 2007 10:00 AM

Community
Ruby
Topics
Performance & Scalability,
Ruby on Rails,
Stories & Case Studies
A recent blog entry about the failure of a Rails based project caused a storm of controversy. Predictably, the side of the debate with stakes in competing technologies saw this as sign of the demise of Rails - particularly as the post talks at length about switching back to PHP. However, some took a closer look at what was actually said in the post. Austin Ziegler points out a few non-technological related problems that broke the project's back:
He ignored his existing experts for the new technology. Neither he nor his employees knew Ruby aside, perhaps, from playing around with it. This wasn’t a technology that was deemed to be appropriate from experience; this was a technology deemed appropriate by management (sorry Derek, you might still be getting your hands dirty with code, but you’re still management).
This points to the fact that the company's software was fully PHP based, with all developers doing PHP development. A software company completely invested in PHP rewriting a big piece of software in Ruby on Rails does raise questions. Particularly, as the original post clearly states that there was only one full time Rails developer plus the writer of the blog entry, who states he's much more comfortable with the PHP environment, while the rest of the developers and the software of the company stayed with PHP.

Another problem Austin brings up is that the project was a rewrite of existing software.
Derek approached the project as a whole-environment ground-up rewrite with a One Big Day deployment, without considering ways to phase it in over time. It’s almost always possible to find interface points where you can replace one broken piece at a time. Ultimately, this is what the Rails folks wouldshould tell you anyway: replace one area at a time, each with a different codebase. Interface them as REST-ful services. Don’t make them depend on a single database schema.
This has been brought up by many. David Heinemeier Hansson points to an article series "The Big Rewrite" by Chad Fowler detailing problems with project rewrites.

The hype cycle is also brought up in this debate. The hype cycle is an idea for describing the process with which products or technologies make a splash in the market. The speedy rise of Rails indicates that hype was one factor it achieved it's current popularity and mindshare so quickly. This is an approach it shares with many technologies, such as Java, XML or venerable AJAX.

One stage of the hype cycle comes after expectations in the technology peak - which is followed by the Trough of Disillusionment. This is the point when real use of the technologies has uncovered some problems or dispelled some myths. It also comes after the period Peak of Inflated Expectations, in which some adopters might believe the technology to be a silver bullet, fit to solve all problems. Raised expectations might explain the fact that a PHP-only shop considered rewriting part of their software with Rails.

While some suggest this to be bad for Ruby, history shows that other technologies went through these same stages. Java, for instance,  experienced this stage long ago when big public projects such as Corel Office for Java project failed in the late 90's or the cancellation of Netscape's Javagator, a rewrite of Netscape Navigator in Java.

Some interpret this recent debate as the backlash for Ruby, although that seems a bit late. Earlier this year, a bigger, more public Ruby based project seemed close to failure. Twitter, a messaging system, built on Ruby, experienced serious performance troubles. A remark that the performance of the Ruby interpreter might be at fault for this, caused a big stir and raised concerns about Ruby.

Now, 6 months later, things look different however. Case in point: Twitter is still up and running, has shed its performance issues, and is still implemented in Ruby. The solutions to fix the problems are now documented to everyone around the net, for instance in slide sets of talks "Scaling Twitter" or "A Small Talk On Getting Big. On the whole, the problems turned out to be architectural.

7 comments

Reply

Rails's future cast in concrete by Steven Devijver Posted Oct 8, 2007 10:41 AM
Re: Rails's future cast in concrete by Robert Hicks Posted Oct 8, 2007 6:37 PM
Ignoring technology mapping by Arnon Rotem-Gal-Oz Posted Oct 8, 2007 4:01 PM
Re: Ignoring technology mapping by Julian Browne Posted Oct 9, 2007 7:47 AM
Using proven technology... by Hank Roark Posted Oct 9, 2007 8:48 AM
"Twitter is up and running" by Joe Grossberg Posted Oct 9, 2007 3:58 PM
real problem for RoR is that it's obsolete technology by Roger Voss Posted Oct 11, 2007 1:15 AM
  1. Back to top

    Rails's future cast in concrete

    Oct 8, 2007 10:41 AM by Steven Devijver

    Rails is an enormous success no matter how you look at it. It caught on big, it opened people's eyes and responses to rails have driven a lot of change. There's no indication or reason to believe rails will disappear, regardless the hype.

  2. Back to top

    Ignoring technology mapping

    Oct 8, 2007 4:01 PM by Arnon Rotem-Gal-Oz

    The main problem with that guy was that he made a technology choice (rails) but didn't follow the constraints and architectural recipes the technology favors such as ActiveRecord versus extensive SQL usaage which he favored I wrote about it in Warning! Technology Mapping has Implications

  3. Back to top

    Re: Rails's future cast in concrete

    Oct 8, 2007 6:37 PM by Robert Hicks

    No it won't go away and that is a good thing. It is a good thing that it makes people "think". I do think Rails will be a "niche" thing but I say that in the best possible sense.

  4. Back to top

    Re: Ignoring technology mapping

    Oct 9, 2007 7:47 AM by Julian Browne

    I got into some protracted email debates about that post when it came out. To be fair to the guy who wrote it, his rationale for the final decisions were pretty sound (although a bit late in the day I must say). But none of his reasons equate to saying ruby-is-no-good, just not right for his particular needs, and with his clear love and base of PHP/SQL I could have told him that before he started.

  5. Back to top

    Using proven technology...

    Oct 9, 2007 8:48 AM by Hank Roark

    I found the blog entry interesting in that I think you could have replaced Ruby (and Rails, a framework) and PHP with any two programming languages and a framework. In _The Toyota Way_, there are 14 management practices espoused. Number eight is "Use only proven technology that serves your people and your processes." Proven means proven to you and your people, not the general world. Seems like the move to a new technology (in this case, RR) violates this practice with the expected results.

  6. Back to top

    "Twitter is up and running"

    Oct 9, 2007 3:58 PM by Joe Grossberg

    Sometimes, they are. I don't even know if they've got "two nines" of uptime, despite all the improvements.

  7. There's really a much more serious problem for RoR - it's obsolete technology. Flex RIA client-tier coupled to services middle-tier is rendering the approach of the middle-tier web frameworks - of all stripes - irrelevant. There's a new generation of a RIA web that is being tooled right now that is way cooler than what's been built by the likes of RoR. There is nothing about RoR that every caused me to have excitement about the web and the Internet. Now, however, Flex - and the new breed of apps emerging on it - have brought excitement back to the web, as it makes possible a whole new approach to the web experience. RoR amounted to nothing more than a (presumably) speedier way to craft the same old web crap experience. It was something of interest to boutique web site development shops that used it for bidding leverage on bottom feeder contracting jobs.

Exclusive Content

Agile in Practice: What Is Actually Going On Out There?

Scott Ambler talks about actual data resulting from surveys made during 2006-2008, showing how Agile is perceived and implemented within organizations.

Building Smart Windows Applications

From QCon 2008, Daniel Moth presents on using Visual Studio 2008 and .NET 3.5 to create compelling rich Windows applications.

Joshua Kerievsky about Industrial XP

Joshua Kerievsky, founder of Industrial Logic, talks about Industrial Extreme Programming which extends XP by including practices dealing with management, customers and developers.

Jeff Barr Discusses Amazon Web Services

Amazon Web Services (AWS) Evangelist Jeff Barr discusses SimpleDB, S3, EC2, SQS, cloud computing, how different Amazon services interact, origins of AWS, AWS globalization and the March AWS outage.

More Than Just Spin (Up) : Virtualization for the Enterprise and SaaS

Cloud services have helped bring virtualization to the forefront. Its full power however, also includes other benefits such as high availability, disaster recovery, and rapid provisioning.

Ruby Beyond Rails

John Lam talks about his path to dynamic languages, some of the problems of making IronRuby run fast, and how the DLR helps with implementing languages.

VMware Infrastructure 3 Book Excerpt and Author Interview

VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.

Architectures of extraordinarily large, self-sustaining systems

Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.