15 years ago, Gerhard discovered magic in the form of Ruby on Rails. It was intuitive and it just worked. That is the context in which Gerhard fell in love with infrastructure and operations.
Our guest is David Heinemeier Hansson, creator of Ruby on Rails, co-founder of Basecamp & HEY, and a lot more - check out dhh.dk.
David Heinemeier Hansson: It’s very easy to lose the connection of shipping that is so pertinent for survival in the early days of a business, where you simply – either you ship or you die. When you get to have a long-running, stable business, you can actually coast for a very long time. You can talk about things for a very long time, and it does not have immediate impacts on your ability to survive as a business. So I feel that it is our obligation. Jason and I in particular, as the founders of these businesses, to continue to keep the pace, to keep the expectations of the pace of what does a successful project look like. What is the, as we like to say, return on effort? Are we spending a lot of time talking about things, worrying about things, or building vastly over-built pieces of software? I think in many ways that’s as much of a dangerous under-building software, or making software that is full of bugs, is to overbuild it. Gold-platin it, as it is also called, where you end up with a system that just overshoots. The customers don’t care about all the bells and whistles that you’ve added to it, but you feel like “Well, we’ve done a good job.”
And you can do that when you end up in this situation where your survival is not depending on shipping. And that’s, I think, perhaps the key constraint that is so powerful in those early days of the business, is that you simply can’t afford that. You can’t just hire 20 people and send them off to work on something for 18 months, and then they come up empty-handed. If that ever happens in a startup, it’s dead; it will not survive.
So you have these pressures, you have these constraints that force in the early days, and in the later days, you have to recreate those constraints through sort of willpower. And that’s actually much harder; it’s so much easier to become flappy when you don’t have to be tight, when you don’t have to be clear.
So I write these shipping principles as much to myself, as much to Jason as I’m writing it to everyone else at the company, that we need to remind ourselves of what we believe to be true. And then we need to live it. We’ve been going at this, with Basecamp, for example, for 18 years, right? The threat is there constantly to lean back, and just – when I say coast though, I don’t mean relax. No one ever relaxes. Everyone is busy all the time. But there are a universe of people who are busy all day long, all week long, all year long, who accomplishes very, very little. Who are not effective; they may be very efficient, and they may use their eight hours a day in a way where things move around, but they don’t necessarily move forward. And I think that’s the key for me, with this focus on shipping. The shipping is the moment of truth. The moment of truth where whatever you’ve built now has to meet the market. And the market
is like turning the lights on. Right? You can have all these ideas in your head about the quality of what you build, or whatever. They’re just illusions. Until you turn on the light, until it meets the market, they’re fantasies, and I love dispelling fantasies; in either direction. Either the fantasy actually turns into reality, and we build something wonderful, and people love it. That’s obviously great.
[22:21] But I also think it’s great occasionally, to release something that people don’t love, right? Like, it’s a way to buttress your own humility here, that building software is hard, even if you’re very good at it. Even if you’ve been doing it for a long time. Even if you have a successful product, building software continues to be difficult. This is why we have not automated it away, despite the numerous attempts over the decades to like, “Oh, actually, programming - we’ve solved it. We’ve solved programming. Here’s fourth generation languages, here’s no code, here’s all these other things…” And it’s not that these things don’t have a place, it’s just that they don’t actually solve sort of the crux of programming, because the crux of programming is to make decisions that matter.
Now, if you can abstract those decisions away, that’s wonderful. It probably means you work in a quite constrained domain. An Excel spreadsheet is one of the most powerful programming environments that have existed in humanity. Right? And lots of programs are written inside Excel spreadsheets. Great. Can you write Hey, an email system in Excel? No. You’ve gotta go down to the building blocks, at the level where the decisions matter. And again, this is this wonderful horizon that I care so much about.
Ruby on Rails, the framework that we use to build all our software, and that I extracted and created from the initial version of Basecamp, lives at this horizon. Can we take more of the things, more of the decisions that don’t actually matter that much, that don’t express themselves in a particular articulation of software, and abstract those away? Wonderful, I love that. That is the domain of conceptual compression, which is one of my favorite things to do, where you take something that’s a big, fuzzy, difficult domain, and then you compress all that complexity, and you make it easy, or at least approachable. And we’ve tried to do that in so many domains.