David Heinemeier Hansson created Ruby on Rails, the popular Web application development framework, as a side-project of a side-project. The year was 2003, and Hansson was studying at the Copenhagen Business School and working on client projects. In his “⁠spare⁠”⁠ time, he devoted about 10 hours a week to developing Basecamp, one of four web-based productivity applications offered by the company he is now associated with: 37signals. Coding in Ruby, Hansson began writing a personal toolkit for the language, which became the basis for the open source project, Ruby on Rails.

Hansson, who moved to Chicago in 2005, thinks there’s a lesson here: some of the best software projects are not the result of a grand vision, a business plan, and hours of meetings. Hanssen hates meetings. Some projects just evolve, with features getting built to address immediate needs. The process ought to be fun. The creative joy, or the lack of it, can be “⁠felt⁠”⁠ in the finished project.

This unconventional view about software development could be seen at his presentation to entrepreneurs at Startup School 08, held at Stanford University last August. Hansson’s message to the group was to forget about trying to be the next billionaire. Instead, build something that is incrementally better than what is already out there. Or as he put it, “⁠open a nice Italian restaurant in the Web space.⁠”⁠ One of his slides offered a simple formula: attract 2000 customers to subscribe to your Web-based service for $40 a month, and you’ll make almost $1 million a year. Do you really need more to be happy? Would you settle for fewer subscribers and, say, $200,000 a year along the way?

I wondered what other thoughts Hansson had about the productivity, priorities, and the life of a programmer/entrepreneur. We started with a central issue in everyone’s working life: time.

You’ve said you had only about 10 hours a week to work on Basecamp, let alone Ruby on Rails. That doesn’t seem like enough time.

Looking back, that time constraint was a blessing in disguise because it forced me to focus on what’s worthwhile. When I was working on Basecamp, I couldn’t afford to mess around with things that didn’t matter. And it meant that the environment I was working in had to be incredibly productive.

You’ve also said that programmers should think about coding only five hours a day.

Absolutely. I think even five good hours is overshooting it for most people. Programming is an inherently creative endeavor that just doesn’t lend itself very well to 12 hour days. My brain, at least, is not constructed so that it can perform at its peak for that many hours a day. It’s not like you can work for 12 hours and get 90 percent of the performance instead of, say 7 hours at 100 percent performance. The productivity decline is much steeper than that. And it’s only when you are operating at your peak that you spot those breakthroughs that ultimately transform your work. With Basecamp, I had to evaluate every single hour of work I put into it. So where another organization might have spent 30 hours on a feature, I tried to find away to do 80 percent of that feature, but in 10 or 20 percent of the time. So I’m a strong believer in working much fewer hours, then re-thinking your work to fit those hours.

You are not a fan of big meetings.

Definitely not. 37signals has a book called Getting Real in which we say that meetings are toxic. I absolutely believe that. Meetings are a very inefficient way of distributing information. A lot of meetings are broadcasting, where one or two people present an idea to a group. There are more appropriate formats for doing that, including just sending an email. But even when meetings are used for decision-making, which I think is the only valid use of meetings, they often drag on for far too long and include far too many people. They’re like time slots on TV: if somebody reserves the meeting room for one hour, that meeting is going to take one hour, even if the decision at hand could have been made in six minutes. At 37signals we ourselves keep meetings to a minimum, and use our own Campfire chat application instead. The chat format forces people to get to the point really fast.

One purpose of meetings is to achieve consensus. Isn’t that important?

That’s another realization I had coming out of the Ruby on Rails development experience. Sometimes you don’t need consensus. Sometimes dictators are a good thing. Sometimes you need somebody to say “⁠this is how it’s going to be―let’s go do it.⁠”⁠ It’s so easy to get into the mode of wanting to please everybody, and the more people you have in a meeting, the more people you need to please―and the longer it takes.

Is that a pitfall of open source development, including Ruby on Rails?

Absolutely. I do think though that open source development generally does better than corporate development on this point because most open source developers are not sitting next to each other. With open source, you don’t show up at the water cooler and start discussing things. You don’t call a meeting and waste time. Often, the code itself is the communications, along with simple mailing list postings.

That said, it’s important that open source communities start out with a very clear vision for what they want to do. When you involve a lot of people, they sometimes want to pull it in different directions before the culture has really cemented. When I first open sourced Rails, I was the only person who had commit rights for the first six to nine months. I didn’t share the key for the code repository until there were enough people who had internalized not just the technology, but the spirit of the project. For this reason, I think people can actually release too early and too often.

What’s your typical work day like?

One of the key things for me and my own productivity is that I get enough sleep. I absolutely need 8.5 to nine hours every night. I’m fairly in tune with my own sense of peak performance, and I can see that if I get just seven hours of sleep, I don’t function as well that day. I usually get up at 9am and start checking up on things, but not really getting into the flow of productivity until the afternoon. Then I hopefully get a good batch of three-to-five hours where I get a lot of good stuff done. When that happens, I’m happy. There are many days when I have just three hours of pure concentrated work, but that may be all that was needed. If I get an important feature done in three hours―that’s great.

What about incoming email, phone calls, and other interruptions?

Too often, I let them interrupt me even though I know for a fact that it’s a bad idea. Interruption is absolutely the enemy of productivity. My business partner at 37signals, Jason Fried, says that when you let interruptions run your day, you turn your work day into work moments. That’s how you get nothing done. That’s why I think it’s better to carve out three to five hours where I don’t let my work life be run by these interruptions. Keeping to this time frame, I can get immense amounts of work done.

I think many developers would have serious doubts about this.

I understand the skepticism―but the truth is there’s not really that tight a relationship between hours put in each day and the product produced. Back when we were working on Basecamp, I was astounded at the amount of work I could get done with just 10 hours per week. I got more done in those 10 hours than many of my colleagues did working full time jobs, 40 hours per week.

In addition to meetings, you also have an aversion to taking venture capital money. That’s quite a distinction from many entrepreneurs who work hard to get it.

I think venture capital money is not only unneeded for most Web startups, but is actually harmful, because it removes you from that all-important concern of turning a profit. VC money postpones those concerns until some later, magical date, where presumably it will come automatically. This is especially true for most Web startups, which simply do not need the kind of money that VCs want to invest. The costs of starting a new Web business have plummeted over the past 10 years. Now you need virtually nothing except your time. All the infrastructure costs of getting a database, a Web framework, a programming language―all of those things have been rendered free by open source. And today the cost of server infrastructure, at least when you are starting out, is minimal.

More people should be doing what we did with Basecamp: set aside some time and start a side-project. People always say they don’t have time, but most Americans spend four hours a day just on TV. If you just cut out one of those four hours per day, that’s seven hours a week.

Which leads to the other thing about venture capital money. People worry that without that funding, they are going to risk their life savings. But that’s another reason to start working on a business idea while you are doing something else. After we launched Basecamp, it took us a year before the application was enough of a business to pay the bills. So we kept on doing consulting projects on the side until it was profitable enough to switch over. That’s a much better model. The whole VC dreamland plays into people’s fantasies of the buy-out at the end of the rainbow. And that’s not going to happen for most people, especially now. On the other hand, the world still needs new businesses with great ideas. Our business is still doing fine even though we are in a recession, and that comes from our initial focus of making sure that we were making money from day one.

What about that dreamland? What’s wrong with thinking big and dreaming you will sell your company to, say, Google?

Way, way too many people have this notion that they’ll do whatever it takes right now―and then something magical will happen: “⁠I’ll get bought out, I’ll be a huge success and then my life will be great.⁠”⁠ It just doesn’t work like that. I’ve talked to a good number of entrepreneurs who have built a successful business, sold it for a lot of money―enough to retire to the mythical beach and sip margaritas all day. And what happened? Six months later they are back in the game because humans are not meant to be beach potatoes. We don’t get any intellectual joy from it. So they come back after six months, perhaps with another idea. And chances are this new idea is not as good as their first.