1

2

3

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: 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 you 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.

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.

1

2

3