Why Ruby on Rails Succeeded

A minor phenomenon has swept the Web world in the last few years. Like many things in the realm of software, it was overhyped. I’m talking about the open-source Web development framework called Ruby on Rails.

Few things live up to their hype. But certainly Rails has at least come close to doing so, and the things that come close are the case studies worth examination.

Not long ago, people were asking whether Rails would succeed. I maintain we’re now past the point of asking that question. It has succeeded. Now let’s ask: Why?

Born from Real-World Needs

Ruby on Rails had its first public release in July 2004. It’s now slightly past the toddler stage. And like a human toddler, it was incredibly active and hard to keep up with. By 2005, David Heinemeier Hansson had won the “Hacker of the Year” award for this software package. In 2006, Rails won the 2006 Jolt Award for best Web development tool. So how did this happen? What did Rails do right, and what did Hansson himself do right?

I should point out here that Ruby and Ruby on Rails are not the same thing. The insiders all know this, but the outsiders and newbies may not. Ruby itself is a language, comparable to Perl or Python, dating back ultimately to 1993. Ruby on Rails, of course, is a Web framework written in Ruby (dating back to 2003 or so).

The first “secret weapon” Rails had was that it was extracted from a real-world application. Rails was not the original goal. The goal was a Web application called Basecamp. As Hansson and others worked on the application, they found out—for the hundredth time—that Web development is painful, time-consuming, repetitive and detail-oriented. This made it a good candidate for coding in Ruby.

MORE ON OPEN-SOURCE PROGRAMMING

Getting to Know Ruby on Rails

Microsoft Windows Loses Ground With Developers, Survey Says

Source Code Management Systems: Trends, Analysis and Best Features

In the process of writing this high-level, condensed Ruby code, Hansson started to abstract away the essentials of the interface, and the result became Ruby on Rails. It was born from real-world needs, from working code and from the everyday experiences of developers.

Rails also benefited from what I call the “Write It Twice” principle (which unfortunately lacks a cool acronym). In the process of building a system—especially a large one—a developer learns new information, finds unforeseen issues and problems, and introduces workarounds. Every experienced developer has occasionally thought, “If I wrote this again, I could do it much better.” The rewrite is always clearer, cleaner and better code. It’s not better just in the academic sense, but also more maintainable, more extensible, more powerful, sometimes even faster. The technique of “write it once, throw it away, write it again” is an incredibly powerful tool, but one that is rarely used because of the time and expense. But that is essentially what happened with Rails; it was written once as the “guts” of an application, and then the rewrite was an abstraction that could be used for any Web application.

As Rails (or any system) grows, it accumulates quirks and oddities in the code as surely as a ship acquires barnacles. Software maintenance, like housecleaning, is a never-ending process. But because it was essentially a rewrite, when Rails finally “went public,” it was cleaner and better than many code bases out there.

And speaking of public: I have already mentioned that Rails is open source. That is an important fact. Ruby on Rails can be (and will be) maintained by the people who use it and love it. Features are added as they are needed, almost by a “grassroots” effort.

An Overarching Philosophy

The next successful decision was to use the right tool for the job. To a Web developer, a Web framework is a tool in itself; but I’m talking about one step higher up the food chain. To the person creating a new Web framework, this framework is an application that itself must be built from scratch. What language should we use: Perl, Java, C++, something else? Ruby was a natural choice.

Hansson wanted to make Web development easier, less painful, less error-prone, and faster. He chose Ruby as his development language. Ruby is a very high-level language, saving the developer time and effort; it is an interpreted language, minimizing problems in compiling and building large systems; it is a dynamic language, able to adapt and configure itself at runtime; and it is extremely malleable in the hands of a skilled user. Although Ruby has its drawbacks—mainly in speed and performance—it is a powerful base on which to build a software system. Rails helped make Ruby popular, but Ruby made Rails possible in the first place.

The next thing Hansson did right was to choose an overarching philosophy to which he would adhere—a set of design principles that he chose carefully and followed faithfully. Most of these ideas have been around for years or decades, but it never hurts to revisit them.

One such guideline is what Dave Thomas (of the Pragmatic Programmers) refers to as the “DRY principle” (Don’t Repeat Yourself). DRY simply means that information or logic built into an application should be localized or isolated. It should be stored in as few places as possible, and duplication should be kept to an absolute minimum. This guideline helps to organize the developer’s thoughts and speed development, and also helps make the code easier to modify. This easier modification pays off not just in maintenance mode, but in initial development as well. Ruby encourages this kind of behavior by making it a little easier to code in this way.

Hansson also depends on another design principle that he calls “convention over configuration.” This means that the framework user should not have to do much configuration, or spend too much time “tweaking and gluing and welding” individual components. For example, Rails makes assumptions about the relationship between class names in the code and table names in the database. If you adhere to this standard convention, your code flows more smoothly and logically; if you don’t, you have to do a little extra work.

This has led some people to describe Rails as “opinionated software,” meaning that it has its own way of doing things, and the programmer must either conform or write extra code. In some cases, this has made Rails a little difficult to integrate with existing tables and databases (and external legacy applications). But some of these issues have been addressed recently, and we all hope the situation continues to improve.

Another thing Hansson did right was to do it himself. Ruby on Rails, like Ruby itself, started as the unified concept of one single person. Certainly, Rails is open source, with many developers helping to expand it, and that is part of its strength. Hansson probably had extensive advice and assistance even in the early stages. But it started as the dream of one person, the vision of a single individual. I don’t know what others may call this, but I call it the “Committee of One” principle. (I wish I had a cool acronym for this concept.)

Great achievements are not begun by committees. If a committee designed a hamster, we would be lucky to get a duck-billed platypus. The Unix operating system was originally put together chiefly by one individual (with a second person joining soon thereafter). Linux was originally the pet project of one man. Perl, Python and Ruby each started as the dream of one person. After a project is under way, many people may well get involved. However, we remember Christopher Wren for his masterpieces of architecture, even though hundreds of people contributed to their construction.

Technical Excellence Isn’t Enough

This article would be incomplete without mentioning marketing. We know that history is littered with the corpses of dead products that were technically superior. Technologies, languages, products—they all need to be marketed well to reach a “critical mass” of popularity and to keep user attention. Here, Hansson did at least three things right.

First, he approached his task with near evangelical zeal. He went to work with the enthusiasm and energy of a car salesman on a triple espresso. The combination of a good product and a good salesperson is a powerful one; as we all know, sometimes a good salesman can sell even a bad product.

Second, he went to the right people. He went straight to the developers. He didn’t write articles or hold seminars for upper-level management. He implemented his ideas, and he showed them to people who were doing the same kind of work. Rails therefore found its way into use in a bottom-up approach rather than top-down—which is usually more effective in ensuring the popularity and life span of a piece of software.

Third, Hansson marketed creatively. He used video. This is important because of the “eye candy” effect, not just in this post-MTV generation but in our culture in general. But let’s look beyond that. Not only is video more engaging, but it’s also proof to the lazy person that the software works. We get to watch it work instead of bothering to download and install it and play with it. Video is engaging not only as a marketing tool, but also as a teaching tool.

So what lessons can we learn from the success of Rails? It always helps to remember the old marketing advice to “find a need and fill it,” and it’s always wise to remember that technical excellence alone is not enough.

I maintain there is much to learn from the Rails phenomenon. Don’t repeat yourself; don’t put a burden on users; don’t design by committee (but do open-source when you release). Be passionate in your work and creative in your marketing. If you apply these principles to your projects, they will at least go more smoothly. They may even be successful. If they are not, remember the final element of success, which is luck. If we can ever figure out how to be lucky when we need to be—well, we will all be David Heinemeier Hansson.

Hal Fulton is the author of The Ruby Way, now in its expanded second edition. He was one of the early adopters of Ruby in the United States, having started to learn it in 1999. Fulton has two degrees in computer science and 20 years in the industry, including several years of teaching experience. He lives in Austin, Texas.

The rest of the story: Fulton is roommates with a cat with the suitably droll name of Meg, short for Megabyte. He is a direct descendant of the first man ever to lock his keys in his car. His short stories have been rejected by some of the finest magazines in the country. On rare occasions he plays chess and piano, both incredibly badly. He spends his spare time putting Slinkys on escalators and passing counterfeit bills to homeless people.