David Heinemeier Hansson is the Danish programmer who developed the open-source Ruby on Rails (often called ‘Rails’) and so created one of the most popular tools among web developers. It won him the Hacker of the Year Award in 2005.

He helped transform the forward-thinking software firm, 37signals, from a consulting company to a web application company by writing the company’s first major release Basecamp, an online project management tool and then released the software that underlies it as an open-source web development framework.

Since then, Ruby on Rails has been used to build several high-profile websites including Twitter and YellowPages.com, and is now being adopted by organizations such as the BBC and LinkedIn.

Many of its converts have been won over by its opinionated philosophy.  Because Rails is Open-source, its development is being driven by a daily contribution of code from thousands of volunteers.

‘I actually tend to find the most rewarding progress to be the cumulative effect of thousands of tiny improvements,’ says Hansson.

 ‘That’s what sets Rails apart from many of the also-rans. Yes, we’ve had the pleasure of popularising tons of major improvements to web application development, but the secret sauce is really the thousands of little things that the vast network of contributors have decided to care about.’

The popularity of Rails has spawned imitators in other programming languages – it’s already been ported to JavaScript and PHP and programmers at the BBC have recently developed Perl on Rails. Its mainstream adoption has been boosted further by its inclusion in the Mac’s latest OS.

Hansson points to what he says is ‘a natural cultural allegiance’ between Rails developers and Apple users:

‘We appreciate the same things. We find happiness and passion in things that are beautiful, tastefully executed and help us get the job done faster. The fact that Leopard ships with Rails is only a natural extension of that cultural bond.’

With this increase in attention, Rails is undeniably becoming more commercial. This is something  that Hansson doesn’t mind at all.

‘I have absolutely no problem with commercialism. What good is it to enjoy doing Ruby on Rails if you have to return to the Java or .Net mines every morning to slog through another day? We want people to be happy doing real work, making a real living.’

David has also written three books including Re-Work a book about starting and running businesses in a better way. The book reached the New York Times, Wall Street Journal and Sunday Times best-seller lists.  

When he’s not working or writing David races sportscars and has competed in the World Endurance Championship LMP2 class at Silverstone, the Spa-Francorchamps in Belgium and the 24-Hours of Le Mans, the world’s oldest active sports car race in endurance racing.

RM:

David, in general do you feel programming languages are getting better over time?

DHH:

It seems like revolutionary changes in programming languages are getting few and far between. In the 10 years I’ve been working with Ruby, there hasn’t been a single big event in programming languages where I thought ‘Wow, I can’t miss this!’
On the other hand the rate of iterative, gradual improvement is as high as ever. The open source model of constantly improving on a solid core idea is alive and well. Ruby itself might not feel materially different from when I picked it up in 2001 at a first glance, but there has been thousands of small improvements that all add up to a large step forward in usability.

RM:

Do you think we need to get better at predicting what we’re really going to need in the future? And do you think programmers display intellectual curiosity about how programming languages developed, what influenced what, who did what and what is now considered a mistake?

DHH:

I don’t think predicting the future is a generally applicable development model. When we encounter new problems that are poorly solved with today’s programming languages, we’ll see people interested in improving them.

RM:

What part of Ruby on Rails was the most difficult to write?

DHH:

Active Record. Crossing the mismatch between an OO programming language and SQL is fraught with danger. It’s very easy to go too far. To not respect the underlying relational model and think that everything should just adhere to the OO paradigm. Striking the right balance of allowing the best of both worlds to shine was tough but it was very satisfying to get it right.

RM:

It’s one of those things about Active Record. A lot of people avoid it because it feels like the class is doing too much and many prefer to use Repositories that return business objects. How did you get Active Record in Rails to work so naturally?

DHH:

I looked at all the options before settling on Active Record. By far the easiest and simplest code came from using that pattern over something like a data mapping or similar. So that made the choice simple.

RM:

Am I right in saying that Rails was originally a toolbox which helped you build Basecamp or was it the other way around?

DHH:

It’s more the other way around. First there was Basecamp, and then I extracted Rails from it. I built a bunch of general-purpose libraries and frameworks in order to build Basecamp with Ruby and then realized half-way through the process that this could benefit others as well. I was extremely aware of tools that weren’t necessarily helping productivity so I sought out tools that might help.
That’s how I found Ruby. It was such a nice experience for me and a nice productivity booster. I was coming from PHP and had also looked at Java and other environments and I wasn’t finding anything that would allow me, as a single programmer, to deliver all this stuff.
And I then built Ruby on Rails to allow me to build Basecamp and drive this project in the ay we wanted to, because we didn’t want to bring on any more programmers. We wanted to keep those constraints that we had and so we just had to make tools that allowed us to do that.
And I think that’s also a big explanation for why Rails is having the success that it is; it was born in an environment that was so focused on productivity and was so focused on being able to deliver within constraints. I’m building Rails while I’m building Basecamp, rather I’m building Basecamp, and every step of the way I’m extracting Rails.

RM:

On your webpage you mention beautiful code. What to you are the characteristics of beautiful code?

DHH:

Beautiful code is similar to beautiful prose: Succinct, it has flow and rhythm, and it’s an expression of clear thinking that doesn’t jump around different layers of abstraction all the time.

RM:

So do the lessons of writing English for a human reader help you with writing all aspects of code? Are there any trade-offs for example if efficiency is important?

DHH:

Absolutely. I find that the best programmers, at least best high-level programmers, tend to be great writers as well. Programmers who wish to improve their code should improve their writing. Yes, occasionally you’ll have to sacrifice beautiful code for speed, but that’s an optimisation to make only after the fact that you’ve proven something to be too slow. Never upfront.

RM:

Is there an upper bound on how big a piece of software can be and still be beautiful?

DHH:

Most likely. It becomes exponentially harder to keep things succinct and coherent the larger the work. I try not to press those limits, though. I find it far more interesting to focus on how little software I can write to solve a problem than how much.

RM:

Much of what 37Signals offers has been driven by the company’s needs rather than what people have asked you for. Is the philosophy: innovate for your customers rather than them driving your innovation?

DHH:

In my experience it’s the only way to make something great. When you’re trying to guess what someone, somewhere might use your software for; you’re likely to build a bloated mess rife with options and configuration points. If you’re building for yourself, you get the proper feedback on what’s enough.

RM:

You’ve been the mainstay of developing products including Campfire, Ta-da List, Backpack any one of which could have been a business in itself. If 37Signals was a larger company before developing these products would they have been  made still?

DHH:

Smaller groups and companies carry less mass so they have an easier time  changing  direction. This means trying different things, building new products. Because the  tools and process we work with are so productive, we can appear to be a much  larger company than we really are by putting out a number of different products. But our goal is to keep the head count low.

RM:

Is there anything you would have done differently when you launched Basecamp?

DHH:

I don’t spend much time looking backwards and thinking about regret. Onwards and upwards!

RM:

What been the most surprising and rewarding thing about running a business?

DHH:

Providing a stable, fulfilling environment for employees who want to stay with us for their entire career.

RM:

Can you remember any hair-raising moments?

DHH:

We’ve had plenty. When we were first starting out, I was the only programmer and systems administrator. I finally took a vacation to Hawaii and of course Basecamp crashed while I was on the plane. So I had to spend the first few hours after we landed sorting things out.

RM:

Do you think software patents are a good idea?

DHH:

%!*k  no. They’re devil spawn and need to be destroyed.

RM:

Is this because all software isn’t some single invention but a complex set of  very detailed rules? Also patent don’t lead to competition but rather stifles it?

DHH:

Patents in general are a strenuous case, but patents on software is like patents on math or writing. It doesn’t make any sense. It certainly stifles innovation and  breeds trolls who extract value from society at large.