David Heinemeier Hansson is one of the most influential voices on the Internet. He is the author of the immensely popular Ruby on Rails programming framework, is a noted blogger and media figure, and is elegantly opinionated when it comes to the best ways to make great software. People follow David's lead in droves, and for good reason: as a partner in the multi-million dollar company 37signals, David is one of the most successful young entrepreneurs in today's Web economy.

Creators of Basecamp, Campfire, Highrise, and Backpack, and authors of the widely read Signal vs. Noise blog, 37signals is an advocate for all things simple and beautiful. We are delighted to share this interview with David about a range of topics—from software development to the productivity gains associated with making people happy.

Umbaugh: David, thanks for calling in today. It's wonderful to have you with us.

DHH: Happy to be here.

Umbaugh: Your company 37signals is really successful, you have got an enormously popular blog and you've written several books. You built a great open source programming framework that people just love, and you're actually making money selling software on the Web. Why are your ventures so successful?

DHH: Well, I think the biggest reason is because we don't identify ourselves too much with the whole notion of the Web world. We identify ourselves more with the notion of a small business operating under proven approaches—like the crazy idea of charging money for products, which seems like a lost art for a lot of Web startups out there.

The best example of how we try to be just like a regular business is that we try to maximize our profits and minimize our expenses. No news there. The wonderful thing about working with the Web is that it's in some ways easy to do both things. It's much easier for us as a 10-person company to reach a huge audience than it is in the traditional world where small companies have a hard time getting heard. With our blog and our book, the Web really gives us a platform to present our products.

In many ways, it's very productive, easy and cheap to build new applications if you have a good idea and an eye for what you want that you can actually accomplish with a small team. Our whole approach is to stay as small as we possibly can and have an influence through other means than just throwing a ton of software out there.

Umbaugh: 37signals had several successful products on the market. Were you ever tempted to give products away for free and use advertising to generate revenue?

DHH: No, never. I don't think that that's an attractive business model at all. There are a lot of people who focus on creating an audience and just get users for the sake of getting users. To me, that just isn't interesting.

For me, it's interesting to get users who like your stuff so much that they're actually seeing real value from it, and thus are willing to pay for it. That's much more of an affirmation that you're doing something worthwhile rather than just getting a lot of users who want to use your stuff for free.

Most of the people at 37signals have been involved with other businesses and have seen what happens when companies don't charge for their products or services. If you don't start out charging money for your products, then you have to do something else. That usually means taking venture capital money or taking some sort of investment to fund your growth. That typically doesn't lead to a healthy happy work environment. I mean it certainly can. There definitely are companies out there who made it work, but I'd say the majority of the VC-funded companies I've talked to—their practices, their lives in the workplace—are pretty far removed from what I would call an ideal situation.

Companies too often merely try to please users and get them to pay for stuff just to satisfy investors, satisfy the three to five-year exit window, and satisfy other external demands. Those are just distractions. For us at 37signals, we've managed to create a good situation in large part because we've been able to cut out distractions.

Umbaugh: Your book, Getting Real, outlines your software development process and your business philosophy in general. What are some of the core values you put forth in Getting Real, and how do you think software developed using that philosophy ends up benefiting the end user?

DHH: One of the big themes in Getting Real is the notion of less software. I think way too many companies and teams try to overachieve by building a ton of software, by building tons of flexibility into their software, including tons of features and by imagining all the things that somebody out there might need in some way, some day. I think that's a really hard way to develop software because it's so much fumbling in the dark.

What we try to do and what we advocate in Getting Real is focus more on needs that are closer to you, things that you can directly relate to, things that will directly determine the quality of something. For us, on both the business side and the software side, our approach is simplicity. Simple alone is a huge feature that's often vastly overlooked. When people compare software products, they often compare checklists of features. In other words, the product that has the longest checklist appears to be the best.

Well we try to do exactly the opposite. We try to "under-do" our competition by doing less than they do, by having the shortest feature list. That is, in essence, our biggest feature.

When we do customer surveys every few months, the number one thing that everybody says that they like the most about our products is the fact that they're simple. Simple sounds in some ways, like a cliché. Nobody would say, "I want to make complex software." But they do say things that amount to the same thing. "I want my software to have tons of features. I want my software to have endless flexibility." Well, all these things are in essence saying, "I want complex software." We're willing to take a stand for simplicity in software. We're willing to say, "You aren't going to get all the features you think you might need some day, you're just going to have the basics executed beautifully. You're not going to get all the flexibility you might imagine that you could need, but we'll give you some." We're going to have opinions and we're going to instill defaults and we're going to package it up.

We keep comparing ourselves to the notion of chefs. When you walk into a high-end restaurant, you really don't get a whole lot of choice. Usually, the hallmark of a high-end restaurant is the chef's menu. The chef prepared courses of a dinner in advance where he made all the choices. You eat there because you trust the chef's judgment and want his taste. Well, we try to do the same thing. Instead of just giving you a super-long menu, we'll just give you this set course of plates and you'll have to trust our judgment on it, and I think you'll end up with a much tastier meal in the end.

That's one way we describe how we're trying to be different from people out there, and we're trying to convince others that they can do the same thing. There's so much software out there that's just endlessly complex, that has too many features, that has too much flexibility, and it ends up not being used because users can't relate to it; they can't get into it. It feels too complex. It feels intimidating when what they really need is just a small subset of what they're given.

But most companies out there are afraid to give them just that small subset because everybody we're talking to is saying, "We want more features; request this, that and the other thing." It's actually funny—in our customer surveys, everybody says the number one feature they like about our products, our approach and our company is that we keep things simple. Then in the very same breath, they say, "Oh, I love all this simple stuff. By the way, please add A, B and C."

It's incredibly hard to help people realize that if we added their A, B and C, and everyone else's D, E and F, they wouldn't like the software anymore. It wouldn't be simple any more. In some ways, we are in constant conflict and we just have to be willing to embrace that conflict. On one hand, you get to please users by doing something that's simple and that doesn't have a lot of features. On the other hand, we have to constantly push back against the very same people saying, "I want this, I want that, and I want the other thing."

That's a rough outline of the approach that we're preaching in Getting Real on pretty much all levels. It's not just about the software. It's also about your policies, your pricing—this whole notion of keeping things simple so that you can have a simple team, so you can execute simply, so you don't need a lot of money upfront, so you need fewer software developers, so you can do it with less marketing. In many ways it feel likes we're stating the obvious, but I don't think it's so obvious after all, because most companies are not doing it this way.

Umbaugh: Software developers add features under the assumption that customers choose software based on its feature set. How would you convince developers that less software is a competitive advantage?

DHH: Exactly as you're saying, everybody out there is doing the opposite of what we're doing. Thus, if you're doing the opposite of what everybody else is doing, you're actually unique.

When you talk to anybody who's used a computer for any period of time, the number one thing they typically say is how much they hate it because it's too complex; it's too hard to use. They can't get their stuff done. So it's not like users aren't already predisposed to wanting something simple. I think this is true all over the place and people are selecting the simple stuff whenever they can.

I can think of two other examples not necessarily in the software world, but look at the iPod. There have been so many other MP3 players out there—a lot of them had FM tuners, they had voice recorders, they have laundry lists of features—but the iPod just successfully executed on a few basics really well and it's overwhelmingly won the market.

Another more recent example, which I really like, is the iFlip portable video recorder. It has pretty much one feature—a big red button that says, "record." When you push that, it records video in not especially good quality, but it's just incredibly simple to use and they're selling these by the boatload.

So I think that oftentimes companies underestimate their customers. They underestimate how willing their customers are to sacrifice features in return for getting something that's actually usable. Well of course the hard thing is to communicate this because everybody's saying they're simple even when they're very much not. So in some ways this is just a slow steady build. But that's pretty much how all business building is—very, very few businesses out there go from zero to multimillion in short order. Pretty much all businesses out there are grown slowly but surely, and I think that that's what we've done as well. Basecamp wasn't this blasting success on the second week of operation. It actually took a full year for Basecamp to be able to pay all the bills at 37signals.

Today of course it's a fantastic business. It's a multimillion-dollar business. We've bee doubling our revenues for the past many years and it's doing very well, but it's built into that. The reason it built into that is that this simplicity really works best as a word of mouth thing. You have somebody using Basecamp or another product of ours, it's simple and they can actually get something done and they'll tell their friends and so on and so forth. The checklist-driven or the feature list-driven approach is much more a shove it down their throats approach because people will perhaps get initially impressed by this long list of features. But when they actually start using it they probably won't like it that much, thus their word of mouth will not be very good, thus you need to keep shoving it down new people's throats who haven't heard about your product from somebody else. That's, in my mind, generally not a very viable long-term strategy. It's very expensive, and it's just not very satisfying. So in my mind, I think companies in general are underestimating their customers. They're underestimating the importance and the success that simple has in the marketplace and could have for them and they're kind of expecting that they'll be success overnight, which is not going to happen in any case so…

Umbaugh: I think simplicity sometimes is easier in theory than it is in practice. If a team commits to writing a piece of really simple software, how do they go about deciding what features to include and which features to cut out? Do they perform user testing, or do they just decide on their own? What approach does 37signals take and how would you extrapolate that outward?

DHH: Sure. So the first thing you do is you don't talk about it that much. You don't try to write it down into functional specs. You don't try to envision your entire product upfront because we simply cannot hold all these things in our head. If you try to write it all down on paper, the easiest thing to do is to add one more feature. One more feature when you're writing it down on a piece of paper is just a single line. It's a bullet point. How long does it take to write a bullet point? Not very long at all. So every single idea whether good or bad, has a tendency to make it into the declaration of what this product should be. In our minds, the only way, for us at least, to arrive at usable software is to build it and use it at the same time.

I'll tell you about how we built Basecamp. We started building Basecamp by building one feature. What is the one thing that Basecamp must do for it to have any value at all? For us, that was the Messages section. If we don't have the Messages section in Basecamp, we don't have Basecamp. So we start building the Messages section and we started using it very shortly thereafter. Once you get rolling with that ball, it becomes almost self-evident what you should be working on next because when you're using your software, there's just one or two features that'll keep popping up as next most important thing to work on.

For us, I believe that was Milestones. So after we got going with communications in Basecamp, the next thing we wanted was this impromptu or really easy planning tool in the Milestones. Once we had that, we went on to do the Files section, and the To-do list and so on.

But the great thing about building software one feature at the time is that:

1. You can pretty much stop at anytime. If we had stopped Basecamp just after we built the Messages section, we would still have a usable piece of software. We would have had the Messages section, which is usable piece of software in itself. It definitely would not have been as useful as Basecamp is today, but it still would be a useful piece of software.
2. Project participants build an immense amount of confidence to see running software that does something useful. People typically approach building software where you write it all down in a functional spec, then a team of programmers goes away for nine months (or year and a half) and they come back with software you don't want anymore. This is that constant struggle of change requests of saying, "Well, this is not what I want," says the customer; and the developer says, "Well, this is what you asked for."
3. There's just no way of successfully describing software in the abstract on any sizeable project. The only way for us, and I believe for pretty much anyone, to arrive at a workable usable good software is to build it and plan it at the same time.
Umbaugh: Okay, so functional specs, they're everywhere. So I think a lot of people think of a functional spec as something that keeps a piece of software organized during the development phase. You just don't agree with that notion?
DHH: I think of functional spec as one of the worst inflictions that has ever happened to the software development world. I think functional specs are a relic of a time when building features was a very, very hard and long process and you had to do all of this upfront planning because once you wrote anything in software, it was pretty much impossible to change it. I don't think that functional specs is a technique that's any longer relevant. To me functional spec is a dead document. It's an illusion of agreement. It's very, very easy for people to sit around a table and just try to hash out what the program should do on a piece of paper.
As we were talking about before, the cost of adding another feature when you're working with a functional spec is the price of a bullet point in Word, which means incredibly inexpensive. It's also a point where you really don't want that much contention. It's hard to make decisions because when it's so easy to add something else in, why wouldn't you just do that? Would you really want that big debate at the table right now, or are you just trying to please everybody who sits around the table? Usually you try to please everybody who sits around the table, and that's really bad way of building good software because you can't please all the people all the time. You're going to end up with something that pleases nobody at any time.
I think this illusion of agreement is especially dangerous in the sense that we can both agree on what a paragraph of text says. Customers and developers do this all the time. Yes, the system will have a Milestone section, and everybody nods their heads and agrees. The developer goes off and builds that Milestone section, takes it back to the customer, and the customer says, "This is not at all what I wanted," because this illusion of agreement when you're working with abstracts (such as paragraphs and words and bullet points) are just so far removed from software that is almost useless, if not outright dangerous. So I think functional specs are a really bad way of developing software because they have all the illusions of agreement.
They try to plan a piece of software into a most unique detail at the point in time where you know absolutely the least about what that piece of software should do. On day one when you're planning some software, you have no idea on how it's all going to fit together. Nobody can hold a complete piece of software in their head and imagine something good. Instead just planning piece-by-piece or inadvertently working small chunks to try to finish something, you get the benefit of doing planning for stuff that's very immediate. You're planning for next week or two weeks from now. It's so much harder to try to plan what you're going to do six months from now to the point where it's at it's downright useless, in my mind. People and programmers and designers are just not good enough to do that. The only way you can do successful job, in my mind—the only way you can create useful good features that people will actually appreciate—is by designing them in very unique detail as you're going along as they're needed right now. So these things kind of have to go hand-in-hand and I see the functional spec is just a really poor way of doing this.
Umbaugh: So what do you instead? If you don't have functional specs, doesn't the process turn into chaos?
DHH: No, I don't think so. What we do is we do the user interface first. So when we're starting a project like Basecamp, we'll have a rough idea of what we want—project collaboration—and that will be the banner for this piece of software, and we'll start with the most important feature.
Where do we go from there? We start designing the screens. Instead of trying to write and own a paragraph and imagine what the software should do, we go straight to the elements. We go directly to the core and we start working in it, start cutting in the materials until we find something that looks like what we want. That's exactly the point in time when we can have a real meaningful discussion about how the software should work.
Developers know this instinctively. When they go to their customer and show them that piece of software that the customer told them to make, well, first of all the software's not going to be what the customers want. But when the developers show customers that piece of software, the customer all of a sudden has a very, very specific explanation for exactly what they want because you're working with something concrete now. They can say, "Well, we don't want this screen here or this is actually not how it's supposed to be. If you move these things around, you understood it wrong and so on." Once you arrive at that point, everything becomes so much easier.
So we try to do the user interface screens upfront. We then move from the user interface screen to the implementation part, which is always a back and forth process when the developers push back: "If you move this piece of the UI a little bit down…if we use a checklist instead of radio buttons…or if we did this, that and the other thing, it would makes more sense." You hash it out as you go. Then when you're done with, say, the Messages section, you try to use it and you tweak it and then you go on to the next thing.
When you have a functional spec, you have the blueprints upfront, which is really an illusion that you have all the answers right away. But we can never design software like that, even on a feature we're working on right now—we'll change it many times over. We would end up with really terrible software if we only got one shot at it. Nobody can make perfect decisions off the top of their head in abstract terms laid out in paragraphs and bullet points. Everybody needs something concrete. Everybody needs something tangible for the mind work at its best.
Umbaugh: When your follow this iterative method of software development, how do you conform to schedules and budgets?
DHH: So two things. First of all, how many of your customers actually receive what they asked for? How often have you done the functional specs, got a budget in on time, delivered the software on time and—most importantly—delivered a piece of software that you actually liked that actually solved your problems to the fullest of its ability? Most people will say pretty much never, because the fact is that the process doesn't seem to work very often.
The software world is ridden with this stigma that we can never deliver anything on time. We can never deliver what the users want, and tons of projects end up canceled. So I say the predominant development process has shown itself to be broken. Once something is truly broken, it's a lot easier to face facts and try something else.
Second thing: There are a lot of techniques you can use to control your costs at the same time you control what the software is going to be like. I'd actually say that the iterative approach is a much safer bet, a much easier way to control costs. When you build something from a functional spec, there's no real sense of priority in the sense of how this software is going to be implemented. When greeted by a functional spec, very rarely do developers start with the feature most important to the business right away. They'll start with the features that they like best, implement that feature to 90 percent, and they will move on to something else. At the end of the cycle, they'll be 90 percent done and they'll have 90 percent left. That's usually how these things go.
Instead, when you work in short bursts time—the boxed development approach, one or two or three weeks at a time—you can sprint during those weeks to develop some features. After three weeks, you're going to have a piece of software that does something. So it's much safer. You can see after three weeks if you don't like the direction this is going, you can now cancel the project. You only spent three weeks of development learning that, well, this is just not the right thing, let's cancel it, instead of waiting the nine or the 18 months for somebody to come back with a complete implementation of your functional spec and have the customer tell you it's not what they wanted anyway.
Now you've blown that entire period of time. But after the three weeks working in the iterative style, you'll have a pretty good idea of where your project is going. I think you can say, "I don't like it. Let's cancel the project." You've only wasted three weeks' worth of money. More likely, you can say, "I like where this is going, and seeing this piece of software I have, let's do another three weeks." It's much more piecemeal. It's much more controlled. It's a lot less scary for customers to work this way because they get constant feedback, so there is less uncertainty on how it's all going to end up.
There's going to be a lot more trust built up between developers and the customer. And developers are going to be a lot happier for it too, because they get to deliver real workable software very early in the process and they get to get real valuable feedback such that they can change their course before they've implemented everything wrong. So the techniques are to use a time box approach—a week, two week, three weeks, whatever you decide on, just schedule for that time box—one time box at a time and you can also just set a budget. So the most this project can cost me is $50,000. Well, divide that by the hours you can buy at a given rate from the developer and you'll end up: Okay, we have six boxes of three weeks each, so I have to arrive at some usable software within the scope of six times three weeks. Well, that's pretty cool because you can now see after you've spent one of these time boxes, am I getting the right way, am I liking where this is going, do I need to change the course, and you can constantly alter and adjust where the project is going. And if you're happy after four weeks, if you like the software that you have then, fine, you just stop. If after six weeks, you realize that the original budget is spent but this software is so valuable, you're getting so much good stuff out of it that it's going to be worth another $50,000, you just keep on going.
It's just to my mind it's a lot safer way of developing software. It's a lot more likely you'll end up with software that you'll actually want to use and is developing some value. But I understand that it's scary because it's not how most people do things and they kind of have a tendency to want to know exactly upfront what something is going to cost. That's completely natural. The only problem is it just doesn't work. There's no way that you can ever pinpoint exactly what something is going to cost when you don't know what that something is. That's how you get into the whole functional spec thing where you get into the illusion of trying to figure out what the something is actually going to be, but it just doesn't work.
Umbaugh: Is facilitating iterative development environment part of the reason you chose to create Ruby on Rails?
DHH: Oh, definitely. A big part of why this shift is happening now versus, say 15 years ago, is that the cost of software development has dropped radically. Tools have become much more productive, making it much easier to implement something of value. It's become feasible to talk about delivering real business value within the scope of one week, or two, three weeks, or whatever your time box is.
For us, our constraints were even more extreme. When we started working on Basecamp, I was still in school. The other guys were working on client gigs. I had 10 hours per week—not per day, per week—to work on Basecamp. So I needed something that was productive enough that 10 hours of programming time would yield concrete benefits. Frankly, the other environments that I'd been working in—PHP and Java—were not giving me a good value for of my ten hours of investment.
It was really just a great realization to discover Ruby and use tools that fit my working style and could help me deliver something useful, meaningful within the scope of just 10 hours. That's what Ruby is optimized for: extreme productivity under pretty harsh constraints, like having teams with a single programmer who has limited time.
Those constraints led to interesting choices in the design of that framework that just wouldn't have arrived otherwise. I think it's very apparent when you look at mainstream tools such as C and Java—how they're just not designed for resource-constrained operations, especially when the resource is a human resource. They're designed for big teams, million-dollar budgets and year-long implementation. On the other hand, Ruby on Rails is designed for something more like this: "Hey, we want an application done in three man-months. Let's use something that will allow us to get that done."
Umbaugh: You've been outspoken about how Ruby on Rails was designed to make programmers happy. Why do you think that's an important value for a programming framework?
DHH: The interesting part of Ruby on Rails was getting really high productivity. I asked myself when I am working most productively. When do I just knock out features and just get a ton of stuff done? I get a ton of stuff done when I'm really pleased with the implementation of what I'm doing, when I'm really pleased with the coherency and in some ways the beauty of the software that I'm creating. When I'm writing beautiful software, it just seems to fly off my fingers and I get a ton of stuff done.
I was really having a hard time writing beautiful software in Java and PHP because those languages and platforms just weren't, let's say, making themselves readily available for beautiful implementation—at least in the way I use them. So when I finally discovered Ruby, I discovered a programmer language that allowed me to write these beautiful programs. And I realized that that was the number one thing that would shoot up my productivity: being motivated by beautiful software. By writing software that you like just makes you so much more productive as a programmer. Up until Ruby on Rails really made that a theme, it was somewhat neglected that the programming environments should really cater to the programmer, not the other way around. Programmers shouldn't try to bend themselves in those ways to programs, and I think that most other programming environments are just not optimized to the programmer first.
Ruby had it straight in its almost mission statement. Matz, the creator from Japan, when he wrote about why he created Ruby, he wrote that he wanted a programming language that makes the programmer happy, and that was his prime motivating goal. Well, I took exactly the same mission and applied it to just a slightly more specific field—that of Web programming—and I tried to build a framework that would make programmers really happy about the actual code, the actual work that they're performing. For all the feedback I get when I go to conferences, when people write emails, and so on, that's the one I'm most proud about. People coming up to me saying, "I used to not like my job very much. I used to consider whether programming was something I wanted to do just because I wasn't writing programs that were making me happy. I wasn't writing implementations that were beautiful and satisfying, and now I am. I'm loving it now. I'm loving writing beautiful programs. I'm loving be a programmer," and so forth, because that's exactly the experience I had. I didn't use to like programming that much. I used to like programs; I used to like having the results of what I did come to life, but I didn't use to like the actual process that much. After I switched to Ruby, started working on Rails, I never enjoyed programming so much in my life, thus never been so productive doing programming as I've been since I switched.
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.
Actually this is one of my bits I always play out when I came here from Denmark about three years ago: one of the things I absolutely hated was the notion of the construction kit meal, which is this notion that in certain bars you'd get a burger and it comes disassembled. There'd be certain amount of lettuce, there will be some tomatoes, some onions, and so on. It was up to you to put it back together. Well screw that; I just want a meal. I want what the chef thinks is going to be a good meal, and I really don't want to put it all back together myself. That's I believe why I'm paying this guy to prepare food for me.
In the same sense, this is why users are paying software developers money to use their products because the software developer hopefully put some thought into how the stuff should work. So we're really not big into having a whole lot of options. Actually one of our prime motivated design directives is to avoid preferences. Whenever we have to put in or feel that we have to put in a preference in our software, we pretty much consider that a defeat. We were not good enough. We were not good enough at coming up with a reasonable choice that most people would like most of the time. I take the same approach to designing Ruby on Rails. I really don't want there to be a whole lot of choice when the choice itself doesn't matter or when we think that there is a best practice that we could just follow out the gate. Why do we have to leave all these choices up to the user, again programmer, if we could just once for all make a good choice for everybody? I think it's just such a waste of work productivity when you force everybody to go over the same considerations time and time again to make essentially the same choices.
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 out-spend 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.

This article was originally published on the User Interface Resource Center (UIRC). For more info, please see http://uxmag.com/uirc

 

출처: http://www.uxmag.com/strategy/less-is-better