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.
Ruby on Rails obviously have Active Record for dealing with the database; it makes it so much simpler. And most recently, Hotwire, the work weāve been doing on the frontend, to dramatically compress all the, in my opinion, astounding complexity we found ourselves in when it comes to JavaScript development, down to a very small, core group where more people can build the kind of competitive apps that we all want to build, right? But with an iota of the effort. Hey I think is a great example of that. When we first shipped Hey - an email client, by the way, that goes head to head with Gmail, that competes with Gmail. Gmail shipped a - or ships still; when you load the Inbox, it ships 4.8 megabytes of compressed JavaScript, which actually expands to, I think, 29 megabytes of JavaScript. An astounding amount of code, right? Hey, ship, the first bundle - 30 kilobytes. 30 kilobytes with an application that goes head to head with Gmail, in a modern way. Thatās the kind of conceptual compression where weāre talking orders of magnitude less stuff to solve the same problem, in a, in my opinion, far more pleasurable, enjoyable way to work, a far more labor-intensive way to work, and one were, we shipped, we met the market, and the market says, āThis is good.ā