Ruby on Rails: An Interview with David Heinemeier Hansson

by Edd Dumbill

Few can have missed the rise of the programming world's latest star platform—Ruby on Rails. Rails' creator, David Heinemeier Hansson, already wowed the crowds at this year's OSCON and is set to keynote the European O'Reilly Open Source Convention in Amsterdam this October.

Heinemeier Hansson lives in Copenhagen, Denmark, and is a partner at the innovative 37signals, creators of the Basecamp project management web application. O'Reilly Network talked with him about Rails' success and future.

On the Success of Ruby on Rails

Edd Dumbill: Rails is now getting wildly popular. Did you have any idea it would take off as well as it has, back in 2004?

David Heinemeier Hansson: Yes and no. I don't think you can predict, much less plan, the kind of success that Rails is currently enjoying. But I did have a good feeling about the possibility of it taking off, mostly because I felt so good about working in Rails myself. And I thought, if this stuff can improve my enjoyment and productivity so much over the conventional approaches I had used in the past, why shouldn't it be able to do so for others?

I think I represented two backgrounds that are both fairly common in programming. I had been working with PHP for a long time, so I had that exposure to getting things done quickly, caring about seeing results before all else. And at the same time, I had been educated at the university and worked with Java in a J2EE shop for some time. That gave me the exposure to really care about the purity and maintainability that good patterns and practices can give you.

So I was situated at the intersection between two widely popular approaches to software development. The one represented by PHP was quick-n-dirty and the one represented by Java was slow-n-clean. So combining those influences into the ultimate goal of quick-n-clean did give me some confidence that I at least had a shot at appealing to both camps.

ED: What do you think is the key to Rails' popularity?

DHH: There's no one key. That is, there's no single, big innovation in Rails to point at and say "that's why." In some ways, that makes Rails harder to explain because the hook can't be both concrete and a one-liner at the same time.

O'Reilly European Open Source Convention

David Heinemeier Hansson
Secrets of Ruby and 37Signals

O'Reilly European Open Source Convention
17-20 October 2005
Amsterdam, The Netherlands

But let's focus on just one of the keys: Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgement on one form of development over another. Well, Rails does, and I believe that's why it works.

With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.

That's not necessarily an easy sell, though. Just see all the wars through the times over coding standards. If people could just agree on one way of placing their brackets, they could presumably reap more readable and uniform code. But for a lot of people, that didn't work because the trade wasn't appealing enough. Getting a more uniform code base is frequently not treated as importantly as individual "freedom" by a lot of programmers.

Rails essentially tries to do the same as the coding standards did, but the reason it's working better is that the deal is much sweeter. Getting a uniform code base is an abstract, group-centered goal. Seeing your application work in a fraction of the time it took you before is a very concrete, individually rewarding goal.

One characteristic of opinionated software is the notion of "conventions over configuration." If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you're rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that, which all add up to make a huge difference in daily use.

Programming Ruby

Related Reading

Programming Ruby
The Pragmatic Programmer's Guide, Second Edition
By Dave Thomas

Pages: 1, 2, 3, 4

Next Pagearrow