| 1 | 2 | 3 |
Love the code you're with - 2:40 min
|
Umbaugh: So, are there business advantages to developing software that makes customers and employees happy?
DHH: Oh totally. I think that making people happy is pretty much why we’re all here and why we’re all working in software or working anywhere, for that matter. Most people aren’t working in places where making their customers happy is an important factor. To me it’s very hard to make your customers happy if you’re not happy yourself. That has to start from within. You have to be happy with the work you’re doing, happy with the products that you’re producing in order to really truly make your customers happy. It’s very much a positive feedback cycle. When you like what you do, you’re going to create something that’s better than if you don’t like what you do. All things being equal, your customers are going to like you and your product a lot more. I don’t think you can separate the two, really. It’s going to be very hard for a company that doesn’t focus on having happy employees to have happy customers, and I don’t think the companies are going to do very well at all.
Umbaugh: David, we have two other developers from EffectiveUI on the call, Tony Hillerson and RJ Owen. I’m going to let them ask a few questions, okay?
DHH: It’s my pleasure.
Tony Hillerson: Hi David, great listening in today. My question is about giving users choices. Do you think offering users more choice or less is preferable?
DHH: Less choice by a very wide margin. There’s a lot of interesting research going on in this right now, actually. There’s a book called “The Paradox of Choice: Why More is Less,” by Barry Schwartz that discusses a number of scientific studies done in grocery stores. A typical grocery store has about 41 varieties of jams and marmalade available. The study measured how many people would go over to the wall, look at a few different types of marmalade and jam, and then actually choose to buy something and go home. Then they contrasted that to a wall with only three different kinds you could pick. I think the sales on the wall with three choices were something like 40 percent higher.
Then they analyzed all the qualitative feedback that stemmed from that interaction. People faced with a ton of choice very easily became insecure. Am I picking the right one? Is there something else that’s actually going to taste better? They highly doubted their choices and ended up not buying anything at all, afraid of being disappointed.
That research can apply directly to software, at both the infrastructure level of software like Ruby on Rails that appeals to programmers, as well as for end users. Most people just want to get stuff done. They don’t want to sit and tinker. They don’t want to spend time setting stuff up. They just want really good defaults. Again, going back to the chef metaphor, you want your dish coming out of the kitchen ready to eat.
Forget about preferences - 1:48 min
|
For example, in Basecamp, the Dashboard will contain five projects and the five latest things from each project. That’s a good default. You can’t change it to seven projects. You can’t change it to three projects. It’s just five, and it actually does matter. It matters in the sense that it’s a good default and it’s just something you just don’t have to worry about. If you have all these options of how many things you can see in the Dashboard, that’s just another obstacle for you to actually get to the thing that you’re trying to do, which is to use Basecamp to organize your project. You’re not using Basecamp for Basecamp’s own sake.
That’s what I was talking about earlier. Too many programmers are using programs for their own sake. They like tinkering with programs, not necessarily using the programs to solve actual problems, but just because they like software. So it’s very natural for programmers to like to have their software as tunable and tweakable as possible. That’s just not true for the general population, and I also think it’s not really true for programmers, either. Ruby on Rails is probably the least configurable framework out there and at the same time it’s still one of the very most popular frameworks out there.
Hillerson: On a slightly different topic, how did you reach the decision to release the secret sauce behind 37signals — Ruby on Rails — to the open source community?
DHH: Why did we choose to do that? First of all, we don’t do infrastructure software. That’s not the business we’re in, so the secret sauce is actually not Ruby on Rails. We could be using anything else out there and we could probably still arrive at our products. Not as easily and probably not as cheaply, but the secret sauce is really the design of our products, not what we use to implement them in.
We’re not going to gain anything by keeping Ruby on Rails to ourselves. We’re also not going to gain anything or win anything by trying to sell it. There’s nobody out there short of Microsoft or IBM who can make money anymore selling general-purpose infrastructure-level software in my mind. And it’s also not the business we’re in.
We decided that if we open-sourced this framework, a lot of people would use it and hopefully implement a bunch of features that we’re probably going to need anyway, so we won’t have to implement those features ourselves. They’re probably going to find and fix many bugs that we would otherwise hit and have to fix ourselves, so we don’t have to do that. So that made good business sense for us.
Second of all, I mean for us our marketing secret is something we stole from Kathy Sierra. She writes a wonderful blog called “Creating Passionate Users”and a wonderful book series called Head First. The theory is: you can either out-spend your competition or you can out-teach your competition. Well, 37signals is not going to outspend anybody. We are 10 people. We don’t have venture funding. There are a lot of people out there who can blow more money than we can on any number of things.
But what we can do — or at least try to do — is we can out-teach the competition. We can out-share the competition. Again, I keep coming back to this cooking world, who are the famous chefs out there? They are the ones who gave away their recipes. They are the people who wrote cookbooks, wrote recipe books, went on TV, showed how they did the things that they do.
We used exactly the same strategy for our own purposes. We gave away our recipe book in the form of Ruby on Rails. We gave away most of ideas in the form of Getting Real and we continue to give away these internal discussions and so on through our blog “Signal vs. Noise.”In return, we get a lot of passionate users who learn more about the company, who get inspired to do their own thing, and hopefully choose to use our software along the way.
People overestimate secret sauce in general. There’s very little secret sauce out there in terms of software that’s just so brilliant that you have to keep it for yourself. In general, I think that there’s way more value to be had by sharing the software that’s not your core business. So we’re not going to share the source code to Basecamp. That wouldn’t make any sense; that is what we do. But the database driver that Basecamp uses to connect to the 37signals’ database … that’s not specific in any way to what we do, thus makes a perfect target for something we can share.
RJ Owen: David, do you cook?
DHH: I actually don’t, but I love eating at restaurants where I can just say, “Give me what the chef thinks is a good thing tonight.” I hate long menu boards and I hate construction kit food. I love giving somebody who I think I can trust free rein to do the best they can do.
Hillerson: On a final note, tell our readers what you think makes a good user interface design.
DHH: For me a good user interface is a simple user interface. It’s a user interface that doesn’t try to expose or reveal too many features or preferences. That’s pretty much the extent of the general-purpose ideas.
Also, a good interface should focus on context over consistency. We have a lot of interfaces that are subtly different because they have a slightly different purpose even though they could have been shoved into the same template. I think a lot of Web development shops have a tendency to just create the overall skeleton of the site once and for all, and then just plug stuff into it from there on out. We think that’s exactly the opposite way of how you should be doing it.
When we start to design something, we don’t start with the frame, or navigation, or the search tab, or any of that stuff. We try to practice something what our people have labeled “epicenter design.” Try to start with thing itself, not the frame, but the picture. In the Messages section of Basecamp, we looked at an individual message: What should the headline look like? How should the date be formatted? How many paragraphs of text should you show before you have a “more” link? Those are the important decisions to make, whereas the “what color should the sidebar be, or how large it should be” is like window dressing.
We have a slightly different perception of what designers are at 37signals. It is not so much about making things pretty as it is about figuring out what things should be and how they should work. That requires looking at the things themselves and not at the frame, or other elements that will fall into place naturally later. Once you have a really good message design, creating the rest in some ways is trivial.
Umbaugh: It was a privilege to do this interview with you. You’ve been inspirational to my career, and to others who are reading this.
DHH: Sure, it’s always fun for me to talk about these things, so entirely my pleasure.
![]()
About David Heinemeier Hansson
Ranked by CNN Money as one of the Top 50 People Who Matter, Hansson is the producer of Ruby on Rails, an open-source tool that has made it dramatically faster and cheaper to build dynamic websites — a transformation that's done much to help make today's crop of Web 2.0 startups so successful.
Read David’s blog at http://www.loudthinking.com
About 37signals
A privately held Chicago-based company in business since 1999, 37signals is committed to building the best Web-based software products possible with the least number of features necessary. The company’s products do less than the competition — intentionally. In 2007, Time Magazine named the firm one of the Net’s Rising Stars.
![]() |
![]() |
![]() |
![]() |








Back to top