Founders at Work.pdf

314 Founders at Work
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.
So I’m doing what I need to do for Basecamp, then figuring, “Hey, this looks
generic, I could pull this piece out and put it into the toolbox Rails.” And as
time goes by, this toolbox gets larger and larger and somewhere in the process I
realized that this generic toolbox that I had was actually a very useful toolbox
and perhaps other people could use that too to do the same thing we were
doing at 37signals, use less resources and build less software.
When we launched Basecamp, it was 4,000 lines of code—so not very
much. One guy who’s now involved with Rails told me that they had a single
configuration file in XML that was 5,000 lines!
We released Basecamp in February 2005, and by then I knew that I wanted
to release Rails. We went through the hectic time after releasing Basecamp
where we would keep on pushing a whole bunch of new features.
We always give a major update within 30 days after we launch a new product.
Because that’s really something that reinforces people’s feelings about the
project. If they buy in on day one and then they see a major new update after
2 weeks, they’re really pleased. So for us, one of the secrets about how we market
the product is to make sure that launch is not the end. We don’t say, “Whew,
we’re done now,” and then go on vacation. It’s then when you keep on pushing
to show this product is alive.
So that happened in February and then we had pretty much a finished
framework for Rails, but I didn’t want to release it yet, because I wanted to document
it. I’d been using open source software for so long that I was really
annoyed that a lot of it had terrible documentation. I didn’t want that to happen
to Rails, so I kept it back about 2 months, and then pushed it out about 3 or
4 months after Basecamp.
Livingston: Was there ever a time when you felt you couldn’t do all this?
Heinemeier Hansson: Sometimes, but whenever we had those feelings we
viewed them as clues that we were trying to do too much, so we’d think, “How
could we make this feature require less engineering and programming?” And
we got into a pretty good mode that, whenever we wanted to do something new,
we would brainstorm some ideas and try to look for the idea that required the
least amount of work.
And I had this same thing in the development of Rails. When you try to do
100 percent of what somebody wants, you need a perfect match, and it’s pretty
rare that you have a perfect match between what you thought people needed
and what they actually need. If you just try instead to do 80 percent of what
they need, there’s a pretty good chance that you’ll hit a sweet spot.
So Rails is really about trying to get that 80 percent all the time and not
really caring about those last 20 percent that are really specific to the situation
that you’re in. When Rails launched, it was just 1,000 lines of code. So even
though we’ve done all these things, there’s no superhuman strength involved.
We aren’t producing more lines of software than everybody else; we’re just
making each line count for so much more.