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.
Livingston: So, much of your innovation was driven by your own needs, rather
than your clients’ requests?
Heinemeier Hansson: Very much so. It’s good to be market-driven in the
sense that you should know what’s going on, but you can’t let your customers
drive your product development. You need to be able to innovate on behalf of
your customers, but they often don’t know what they want. And it’s the same
thing for programmers. If you went around and asked them what they wanted
in a framework, you wouldn’t get a good product out of that. You need to be
able to source input from a lot of sources, and then have your vision of what it’s

Похожие записи:

• using our product,
• the product is