REWRITE! | David Heinemeier-Hansson, Basecamp | BoS USA 2015

What’s number one on Joel Spolsky’s list of ‘Things You Should Never Do’? — “Rewrite your software from scratch.“ Naturally, David Heinemeier Hansson disagrees.

In this talk, ‘Rewrite!‘ at Business of Software Conference USA 2015, David Heinemeier Hansson, Co-Founder, Basecamp, and Creator of Ruby on Rails explains why he disagrees and discusses his experience in rewriting the code for Basecamp, not once, but twice, with the third version of Basecamp launched this month.

Don’t have time for the full video?

• Notes from attendees.
• Slides from David’s talk.
• Transcript below

Watch the Follow Up Hangout

Hangout Summary Here

Transcript

Mark Littlewood: It’s very easy to create a billion dollar business. In fact our next speaker, who doesn’t really need an introduction, has created a hundred billion dollar business. [laugh] But that’s probably the least difficult of all the things he’s done. He invented Ruby on Rails. He cofounded Basecamp. And he is one of the people that James Snow talked about last year in from Contently in the Level Up thing, where he was talking about his racing driving. And let me welcome to the BOS stage David Heinemeier Hansson who’s going to be talking about Rewrite. [Applause]

David Heinemeier Hansson: Thanks for having me. I think that preamble is exactly why I’m here. And why I don’t go to a lot of conferences. Because a lot of conferences would have a thing saying unicorns are not the greatest thing ever. And wouldn’t stop themselves from gushing all about that unicorns are the greatest thing ever. And I’m in the other camp, let’s say that. I’m in the camp with Mark. I’m in the camp that there’s something far more interesting to work on than to try to join a three comma club.

But that’s not what I’m going to talk to you about today.

“Today I’m going to share a story about a piece of software that I’ve been working on for more than a decade in a variety of forms, and the story of transformation that piece of software has been through”

So, to set the stage for that story let me take you back to the dark days of 2003. The smoldering rubble of the dot com bust was still simmering, mobile was PalmPilot, and the iPod had just barely been released. And in those days we started working on BaseCamp. Software as a Service was still (I think) four years away from getting coined. And people were not used to paying for software on a subscription basis.

In fact, when we got started we didn’t even know what the hell we were doing, trying to charge people on a subscription basis. In fact, when we were building BaseCamp we originally built it with a yearly billing plan. We were going to charge people 450 bucks a year to use BaseCamp. We had it all built out – we had even a billing system for that and I think about three weeks before we were supposed to launch we went to the bank and said “Oh, we’d like a merchant account.” And they said “Oh, that’s great. What’s your business model?”

“Well, we’re going to charge people four hundred fifty bucks up front for a piece of software that they’re then gonna use over a year and then we’re going to charge it again”

And the bank said, “Ha…that’s funny. Umm…No. You’re not going to do that because if you charged them 450 bucks up front and you go out of business in two months, they’re going to come to us and they’re going to want a refund for the ten months that you weren’t there. So, you can’t do that.”

And we went, “Oh. Okay. Uhhh I guess we have three weeks left to launch and let’s do something else. So let’s say that we’re going to charge people fifty bucks a month instead and then build the billing system after we launch.”

So that’s what we did. But, figuring out how to charge for the software was sort of a small part of figuring out what to do with BaseCamp. A bigger part was to try to get people comfortable with the idea at all of using hosted software. Of using software over the internet for something more important than their email or their cat pictures or whatever else they were doing at the time.

And we were focusing really hard on this in the beginning because paying for software subscription was not a common thing in 2003. So we thought really hard about this, and thought about all the arguments we could summon and tricks that we could come up with for why this would be a great idea. And this is actually, this is the original website. This is how it launched in 2004 in February. This is what it looked like. And these were the things we were highlighting.

On the side, and highlighted even further here, Key Features of BaseCamp. It is web based and centrally hosted. Like, that’s a novel thing. That was a key feature of BaseCamp! Which today you’d say, like “Yeah, okay that’s software and people have been doing that for a long time”. Um, we had to highlight this. We had to sell this. We had to make the case that not having some IT person come and set up that Exchange server under your desk was an upgrade and that would lead to a better place for your company.

So, as we were selling the product like this and as we were selling basically the company like this, we sort of started to believe obviously that this was a good thing. That hosted software was a far better model than sending out CDs or whatever else have you. I remember shortly before starting working on Basecamp I had worked at another company where we had the Microsoft folder. I think you could buy a subscription, where they would send you a folder about this thick [gesturing with hands] with CDs of all the pieces of software. Oh, you’d have Exchange Server 2001 and you’d have all these other pieces of software right? So that was the common way of shipping and distributing software. Still, even though, of course, internet had been around for a long time, but people were comfortable having their own machines, within the confounds of their office and that was great.

Okay, so trying to convince people that this was great. As trying to sell software like this, that’s one aspect of it. That’s one aspect that’s informing what we’re doing. Another aspect is, at the time of BaseCamp, this whole Agile thing was really gaining traction. Obviously people had been talking about Agile for a while before we released BaseCamp, but it was sort of hitting its stride. We were figuring out that software, the metaphor for building that, maybe bridges was not the right one. Maybe the engineering principles and approaches to building infrastructure in the physical world was not exactly the same and did not lend as much to software development as previous generations of developers had thought.

So Agile comes out and says, “Umm, hey change – that’s not bad. Change is good. Adopting and responding to change in the positive way instead of in the negative way can actually help all of us.” Which was really funny to me, because I’d gone through a couple of projects that were not Agile, let’s say that. They were very waterfall. And that waterfall process usually went in the way, you’d come up with your spec and you’d say “Hey customers – this is what you want.” And the customer said, “Yeah yeah yeah, 300 pages – that describes exactly what I want to a T. Let me sign on the dotted line.” And so they did. And when they figured out that what they had signed was not what they wanted they went, “Hey! That’s not what I want.” And they went, “Let’s change that!”

And that’s when (I was working at a consultancy at the time) they went [rubbing hands greedily], “Yes, let’s change that. Here’s a change request.” And the customer, funnily enough, didn’t think that was that funny. So, I think that led to an atmosphere of developers hating change, right? We had made this grand design, we committed to this design, and the customer didn’t want it. Business people kind of wanted it, cause that’s a great way to make money, but it’s not a great way to have a good relationship with your customers.

It reminds me a little bit about the story of sort of going to the doctor. “Hey, Doctor, when I hit my knee with a hammer really hard it hurts! What should I do?” and the doctor goes, “Stop doing that,” right? Stop writing software like that. It hurts. That’s…It doesn’t have to hurt. And I think that that was the really positive message coming out of the Agile world at that time that…

“Software does not have to hurt. Change does not have to hurt, and we can figure it out together and it can be much better.”

Wonderful! I bought into that whole hog. I’d been through the other process, so finding this was incredible appealing. Okay, so now you have two factors. You have a factor of us trying to sell software as, “Hey, you don’t have to install it on your machine, you can have it on our servers. And why do you want it on our servers? Because we can change it and we can upgrade it and we can it better and you don’t have to do anything to get all those benefits. That is wonderful, isn’t it?” Oh yes.

So, we have the commercial side of it, we have the atmosphere, the positive atmosphere, and then, that’s the carrot, that’s Agile. And then we also have the stick. Joel Spolsky had a great article in 2000, where he was talking about the worst mistakes in software. And he was using the example of NetScape. And the example that NetScape chose to rewrite the Navigator. And that basically set them back four years, and that was the single worst strategic mistake that not only NetScape made, but that any company could make, right?

“Rewriting software: Terrible!”

Okay, atmosphere of change is good, we can continue to evolve software, as a positive model. Joel coming out saying, “Yeah, yeah, that’s fine. But should you, veer away from that? Should you ever try to rewrite your software? You’re gonna make the single worst strategic mistake you’ve ever made.” Basically he said, you’re going to kill your company if you rewrite your software. It was not very subtle.

Okay. So, we have all these factors at the time. These were all things I’m reading, things I’m being influenced about, things I’m trying to do, right? They’re all going into this pot together. And the pot is stirring, and I’m thinking, and forming my idea, my paradigm of the world, my paradigm of how we should be building software, and I’m completely taken in with this. I’m completely taken in with the idea of transcendent software. Software that is going to live forever. The eternal codebase. That code is infinitely malleable. That legacy is infinitely valuable. That you can change anything, any piece of software, any piece of code can be rewritten.

The Agile world was putting out books like “Refactoring.” Here are all the tactics and tools that you can use to turn anything into anything else. And not only that. As you’re turning these things into other things, if you are having trouble with that, if that hurts, that’s technical debt.

You just made a poor design. But, now worries. We have remedies. We have courses and classes for you to take, conferences for you to go to, and books for you read where you can repent and figure out how you went wrong. Because it is your fault. If software is hard to change, it is your fault. You’re a bad programmer and you just have to learn to be better.

I’m fine with this. I’m on year two of my codebase. Everything is awesome. Uhhh, I don’t mind thinking like “Pshh, those suckers. Ten year old codebases – they can’t figure out how to make a change happen. Lo-sers! They just haven’t figured out how to make good software yet.” And, in part, I tried to help tell them how to make better software. Through a variety of frameworks and talks and so on. Anyway, completely smitten with this notion of transcendent software. In fact, at the time I was thinking, “This codebase of BaseCamp is going to live forever. These exact classes are going to live forever. They might not look in their final form right now, but in a hundred years from now I’ll still be editing this file.” I could go back through the revision history and see “Oh, back in 2000, remember grandson, I made this line!” [Laughter] And we could sit down and and we could muse about that, and people would still be paying me gobs of money for these lines of code that were living forever. How is that not just the most appealing image ever?

And so it went, for the next seven very fat years, we enjoyed the notion of transcendent software. From 2004 when BaseCamp was released, until 2011 where we started having shimmers in our faith, things were good. Very good. Growth was great. Lots of people signing up for BaseCamp. Lots of people telling other people about BaseCamp. Photos in magazines and all sorts of good things coming, right? Users were logging in, we were getting this feedback all the time, “Oh, BaseCamp is great, BaseCamp is great, BaseCamp is great” and we go, “Yeah, BaseCamp is great!” Then as the years went on we went “Yeah, BaseCamp’s great! Yeah…” And then as fatter we became through these seven fat years, the less we started using BaseCamp.

Hmmm. Some disconnect here. Some disconnect. Software’s doing great, business is doing great. I’m not feeling as great about the business. I’m not feeling as great about the software. We start doing other things. We have this amazing thing, BaseCamp, that just goes “whoosh” [gesturing an airplane taking off], and we spend time launching HighRise and Campfire and Backpack and all sorts of other products, right? All this with a company of – what were we at the time? – 10 people? 12 people? That sounds like a great idea, right? Let’s launch like five different products and try to chase all those at the same time while you have this thing that’s just a rocket, taking off.

Hmmm. Okay. Well – a table. Jason, my business partner, has this great visualization technique for software, where he says “Think of your software as though it was a physical object.” And when you think about it as a physical object, a lot of the preferences, a lot of the features and so on, they just start making not a lot of sense. You’re just like like, oh, if I could see that screen as a real physical thing I’d go like, “That’s gross,” like, I’d throw that away. So he uses that as an interface design technique that, if he had to make like a remote like this [shows remote control], how many buttons should it have, how many features should it have, what should the gestures be and the clicks and so forth?

When you imagine software this ephemeral thing as a physical thing, it clarifies a lot of decisions. Well, I’m going to use the technique in a slightly different way. Imagine that BaseCamp is a table. It is made out of wood, and the wood is software, and as I’m still in the mindset and the paradigm of transcendent software, I’m thinking, “This is just wood. Wood can turn into anything. It doesn’t have to be a table. It could be something else.” I like making furniture, and I like making furniture in wood, but we could turn it into something else. We could turn it into this beautiful chair. I have this vision, I have this idea for a beautiful chair. Okay, what do I have to do? First, refactoring: chop off the legs, now I just have a plank of wood. Somehow make that plank thinner? Put it into a press and Voila! I’m gonna have this beautiful stingray chair.

I more or less believed that that was possible in, up until about 2011. Let’s say maybe my faith started wavering in the late 2000s, but this idea of transcendent software, that you could turn one piece of software into pretty much any other piece of software, and that that is a good way to go…Compelling – I was bought in. But, then I started thinking. Um, I’d like to do that. I believed in the idea, that you could turn software from a table into a chair, let’s put that into practice.

Before we sort of went down that whole line, I started thinking, “Yeah, users and customers, they’re going to love that!” I had this great table I was selling, but it was kind of basic. You see that chair, that stingray chair? That was beautiful! Users and customers are going to love that! Then I started thinking, “Oh shit, remember that one time where we tried to remove a couple features? Actually, they didn’t like that.”

How am I going to get rid of those damn things at the bottom of the table to turn this into just a plank of wood, if they don’t really like me taking away features?

Huh, okay, well I guess maybe we just say we aren’t going to take any features away. We’re just going to keep all the same features. I mean, I’m still going to turn it into this beautiful stingray chair, somehow with this table. But, maybe we could just move things around a bit. Like we’re reshaping things. It’s still wood, we’re reshaping. They’ll love that, right? Oh, remember that time when we moved the tab to that other page and then people were really mad about that? Oh, so we can’t move things around either. Huh. Okay, ummm. Maybe they’re not going to love my stingray chair. Shit.

So, the value of change. I look, most software developers look, at the value of change and they just see the value of the change. Like, let’s call the value of change 8. Now, the problem is, that’s pretty much all we look at and like, “Oh, should we do this? Oh it has a value of change of 8. This thing has a value of change of 6, let’s do the one that has 8.” We forget sort of the second part of the equation, which is the cost of that change to people who are already using the system, who’ve already learned how to use your probably poor UI, but they’ve internalized that that’s how the model works and that the tab is on the right side over there and it has these features and they’ve somehow figured out how to make those features work for their workflow, and that’s great.

Hey wait a minute, oh. Huh. They’re not going to love my stingray chair are they. In fact, they’re probably going to fucking hate it. That’s not why I’m making software. I’m making software to make customers happy and users happy. I’m not here to get a net gain of minus two. I’m going to have to come up with something else.

Okay I have all these great ideas for how to improve BaseCamp and make it better. I want to make a stingray chair, but I can’t take away the table. Behold, this is a chair and it’s a table. It does both things at once. Man that is not a beautiful stingray chair. Ugh.

About this moment is when people sort of fall out of love with the notion of transcendent software.

It is that notion when they hit the reality of the cost of change to users they already have and realize that a lot of improvements that they think they could make are going to end up in minus two, not a net gain.

Problem is, builders naturally fall in love with their creations, right? We love our software. I love my software. I love working on BaseCamp. I even love working on that old codebase of BaseCamp. Even years into it I was having a lot of fun. We were doing all the right things. We were keeping up with general change in the industry, we were applying latest principles, we were shaking AJAX dust all over it, keeping it up to date with the latest frameworks, helps if you make the framework, perhaps, but we were and we were feeling good about that. All good principles.

“This was not about technical debt.”

And technical debt was presented as that is the only reason anyone would ever be foolish enough to rewrite their software. It is if they’re so fucked by their poor decisions that they have no other choice but to create and declare bankruptcy. And all this technical debt is mounting up. And that’s where the schism came in, because I was thinking we don’t actually have technical dept. Like, we can add features at a good pace. We have good test coverage. We don’t fear change in that sense. It’s users, it’s the customers. They’re the ones who don’t want us actually to change the thing. Why didn’t anyone tell me about this? Why were we always talking about technical debt as that only reason for why we would be rewriting our software?

I think in part because the conversation, well intentioned, was informed by consultants. Consultants are great agents of change. They get to see a lot of different environments and spend a little bit of time here and a little bit of time there. And they usually get called in when things are fucked, right? Like, you don’t call, we didn’t call a bunch of consultants in when we had zero technical debt and everything was going peachy, right? They weren’t coming in like hey, come in, see this. So, they get exposed to a less flowery, good looking world, right? They get to see all the bad stuff and that’s where they form their opinions from, as we all do. We form our opinions from our experiences and our observations and that’s good.

Well, the observations and the experiences that I was seeing and having from running this piece of software for seven years, they were just very different. They weren’t matching up to the Agile promise of transcendent software and they were not matching up to the prescriptions of Joel either.

What I was finding was that even though to me BaseCamp was this wonderful teddy bear that I loved to hug and squeeze, to a lot of customers it was a fax machine.

They weren’t going to squeeze their fax machine. They weren’t going to love it. It just needed to do the damn thing that they hired it to do. And it did. It sent faxes. People still have these. They don’t love them. They never did. But I guarantee you that there is an engineer at Brother that thought “Oh, the X500, awww, such a beautiful machine. Do you see that tone of blue on there? We sweated over that tone forever, but we got it right.”

 Software to most people just gets shit done. It’s not their teddy bear, they don’t love it. They pay for it and it helps them do their job and that’s great, but we don’t get to accept that because there is a tiny vocal minority of users who do love their software, who do think BaseCamp is a teddy bear. And those are the people most likely to write you and say “BaseCamp is a teddy bear!” Nobody writes you, generally speaking, to say “Hey, Basecamp is a fax machine.” Although, they’ll say it in different words.

In any case, the conclusion that I came to, having been through seven years, fat years, of BaseCamp as my teddy bear, running into the brick wall of users thinking it’s a fax machine, me having these dreams, us having these dreams and visions of a beautiful stingray chair, realizing we’re stuck with a table and we don’t want to make a portable highchair. But the eternal version, this whole notion of transcendent software, was not delivering. We were not happy with BaseCamp. Why do you think we didn’t spend that much time on it? Why do you think we went off on all these directions to do all these other things even though we had this rocket ship taking off? Because we didn’t want to make those portable highchairs. We wanted to make stingray chairs. And you could say, “Well, just suck it up. Realize that you are making fax machines and just put out EX-501 that has two new features. Take nothing away, move no menus around, and live with every decision you ever made since the beginning of time, forever.” Does that not sound wonderful? Would you not love to have every single decision you ever made codified in stone tablets displayed proudly on the wall and then you would have to live under that for the next two thousand years? Hey wait a minute…

Eternal software, eternal versions, it’s not that great for a lot of people and also for a lot of users. We’ll get to that in a second. The problem is, you get these lovely gold handcuffs where money’s gushing in because users are paying for your software, especially with subscription software, right? The number one thing is just to make sure all the users you already have, that they’re still happy, right? Then the money just keeps coming in every month, ah new check, new check, new check. Great. But, you have to stick your arms forward and say, “Okay, I will never change my software again.” And there are all sorts of ways to romanticize this, and I tried really hard to romanticize it because when you do get that check every month and it keeps getting bigger and bigger you’re thinking to yourself, like the paradigm is, “Things must be working. I must be doing things right because otherwise people wouldn’t keep paying me more and more and more money. So, if I’m feeling bad about that, it’s I’m the one who has a problem here. Like, there’s not actually a problem, it’s just all mentally in my head.”

In fact, it’s beautiful to grow old with your customers, right? It’s beautiful! You get to run down this bridge together and then at one point you jump off and it is. And it’s funny, that’s the weird clash. That’s why it’s interesting to me because at BaseCamp we are all about that. We are all about building things for the long term and growing older gracefully with your customers. The problem is if that’s all you do, if you grow old gracefully with your old customers, well, you grow old.

That has a lot of benefits. It also has a lot of disadvantages. You have to have some sort of renewal. Otherwise you just turn into Japan. If you have a birthrate of 1.4 like things are great, things are great, things are great, things are not so great. Things stop moving and at one point you just have a very old customer base, a very shrinking new base of customers, and a bucket. That leaky bucket – you might be plugging all the holes, you might be fixing all the bugs, you might be upgrading all the features the existing customers are complaining about so that no water escapes but some water always escapes. Customers move on from their job and they leave your software even if they consider it a teddy bear. Or a very good fax machine. “I would buy this fax machine again if I had to send another fax but, I don’t have to send another fax so, great job on the X-500 but I just don’t need it anymore.”

Problem is, if you don’t pour in new water, eventually there won’t be any water left in the bucket.

But you can kind of delude yourself that, “Hey, this bucket is more than half full still. That’s just a tiny little hole there seeping out and that’s perfectly natural.” But, if you just keep that on for long enough, the bucket is going to end up empty. The problem is that by the time it ends up empty, it’s too late. There’s not going to be any new water pouring into an empty bucket.

You have to make changes while things are good, which is the hardest possible time to make a change. Nobody wants to make a change when everything is going finely. Nobody wants to make a change when the checks are growing every month. Nobody wants to make a change when the engagement charts are going like this and the sign up charts are going like this. No, they’re like “Hey, hey don’t mess with anything here. Things are working. All right, just stay calm and work on the X-502. That’s where your creative output should go.”

Well, this was why we started feeling not great about working on BaseCamp. We were not competing with our best ideas. We were competing with our ideas in oh, 2003. That year we talked about just right after the dot com bust. That year before AJAX and smartphones and all that other stuff. That was the formation ground for all our best ideas. Are we really that arrogant to think that the ideas we had in 2003 were still going to be the very best ideas in 2011? I mean, I’ve been accused of being pretty arrogant, but I ran out of steam on that one in like 2008. That’s about how long I could keep up the charade for myself.

So, in 2012, actually starting in 11 after the seven fat years, we decided nope, no more eternal version. No more transcendent software.

We have to do something else. We have to start competing with our best ideas. And I think the reason we had to start competing with our best ideas was we were not confident that – actually, let me put it another way. We were confident that if we were competing with our best ideas, we’d be doing great. I would face any competitor if I had my best ideas at my arsenal to fight. If I had to fight with ten year old ideas, not so sure. Not so confident anymore.

So, how are we going to do that? How are we going to fight with our best ideas? We have this wonderful piece of software that plenty of users are still considering their teddy bear. People are writing us about feeling good about it, but we’re not. And new users are not. New users never tell you. Prospective users very rarely tell you anything. People who showed up at the BaseCamp homepage in 2011 and chose not to buy because our ideas were no longer good enough, how often do you think we were hearing from them? Never. We were hearing from this broad base of existing customers who very much would love us to just keep plugging those little holes. So it gives you a very screwed and skewed sense of what reality is. Because as we talked about, reality is what you perceive and what you experience and what we were perceiving and experiencing was from this narrow, in fact tiny, sliver of the world’s population that happened to be using BaseCamp. Not a representative sample as they say.

So, how are we going to start competing with our best ideas? Well, the easiest thing in the world to justify is to improve what we already have. Even if we accept that we’re going to make some radical changes, it’s not going to be the same version, something’s going to change, the easiest thing would still be to start from like that table. Just say okay we’re committing to carving off the legs, we’re going to commit to making that board thin, and then we’re going to try to bend it into something else. You’re not giving up everything. And the reason that is is throwing out that whole damn table, that sounds really risky. Then we’re starting from scratch all of a sudden. Well what about all of the things that we built up and all the work that we put in – we can’t just throw that away, right? Let’s reuse it. Let’s start from that base. And that was exactly how we started. We started thinking “How can we make a new version of BaseCamp that encapsulates our very best ideas using all the old stuff we kind of already have? Or, I mean, we’re going to reconfigure it of course, we’re going to refactor it and we’re going to move it over here…”

And ultimately we decided that Louis C.K. was right. “There’s a huge challenge in not having your old act,” he says. He throws his act out every year. But I think you can rise to the occasion. But you won’t rise to the occasion if you don’t put a void there. You have to take away your old material from yourself to do your best work. You have to put a void. That is scary.

Seven years into this thing we have it made and everything is coasting and now we throw it all away and we start with that? Okay, we don’t start with that. I mean, we have some frame. We have some idea. Like, first there was the terror, like “Blank page – yikes!” Then, all right, we’re gaining our senses. Okay, take it easy, calm, think it through. There is a box. We have a box. We’re not starting from square. We’ve figured something out. We’ve figured out that we want to help people make progress on projects together. Actually that’s a pretty good box. Like that’s not a blank slate, that’s something to work with. And when you have something like that to work with, you decrease the scope. All of a sudden this becomes a manageable thing you can fill in with something good, something new, and it’s not so scary anymore.

And we realized that that was actually the most important thing. That the compilation, the exact implementation of that vision, the actual code that we had, was not as important as us figuring out like, this is the space we want to be in, this is the opinions we want to have, that project management is mostly about communication. It’s not about gantt charts, it’s not about all these other things. Well, it is for some people, it’s not for us, that’s not the product we’re putting out. What we’re putting out is this curated set of tools and features that help this happen.

So, once we accepted that, that we were actually starting from scratch, we were starting from a vision, a mission, we could start thinking about that. So, we started thinking “Hey, here are some of the things we don’t want to do anymore. Here’s some of the decisions from 2003 that we don’t want to stick with in 2012.”

FTP hosting was something we used to offer. In 2003 we were thinking, “Storing users’ files on our computers? That sounds crazy! What if we get hacked?” and then everyone in the world just decided, “Ehh, pshh nobody’s ever going to get hacked. That’s crazy. Let’s just put it all in the cloud.” This was still 2011 mind you.

So we thought “Yeah, yeah, yeah, let’s bring it all in house.” Actually we had already brought it in house in I think 2006 or 2007. This was just for old users, this was that one leg of the table that still had to be there because we still had a bunch of users who had signed up in 2003 and they were using their own FTP servers and it was really complicated to migrate all that data so had to keep that feature there and every time we did any new feature that had anything to do with files we had to go like “[snap] Did you think about FTP hosting? You’ve got to make complications and amends for that. How are you going to do the previews for the files that are not hosted on your…oh. Okay, that’s a different process.” So that one was high on the list, let’s get that out of there. Bunch of other features, bunch of other things, bunch of other ideas that we thought, “That’s going to be great. Let’s get rid of that. Awesome.”

And then we said “We can do all these other things, all these other features. Oh we can have groups and we can make things faster and drag and drop and we can use all these new technical things and that’s great.” But, if we were going to get stuck, still, with that base of having to tweak the table into the stingray, that was going to be a local maximum. We’re still going to be constrained by the quality of the wood that happened to be that table, the size that that was cut in, all those constraints of the materials that we were already working with, we’re never going to reach the ultimate peak of what we can do. We were never going to be able to compete with our very best ideas, our very best implementation. To do that, we had to start over. We had to rewrite. We had to rewrite the whole damn thing. We had to say “Joel, you’re wrong. I’m sorry. We’re going to rewrite it. It’s not going to be the worst strategic decision ever. It’s going to be the best strategic decision ever!”

[sigh] Okay. I hope at this point in the talk I’ve convinced you that maybe, just possibly, maybe rewriting your software is not the end of the world because the great thing about this is it’s 2005 and we rewrote our software in 2011 for the first time. Launched in 2012. And do you know what? It went great. Better than great. Right after we launched the new version of BaseCamp, signups doubled. How were we going to find that out if we were reconfiguring this existing thing that we already have? Doubled means that half the people the day before who came to BaseCamp looked at the thing and said “Ehhhhh, yeah. That one’s not for me. I don’t want that.” And what we thought was “Well it’s just because they don’t have a project at the time” or some other reason or the boss won’t let them pay for it or any of the other self delusional reasons you can consider why people aren’t buying your product except for the fact that they don’t want to buy your product. Nobody wants to hear that, right? Like, “My product is perfect, they’re just ignorant for not realizing that.”

Okay, so have a new product, things are going great. What do we do with the old one? I know.

Someone somewhere (and I haven’t traced this down. I hope somebody will) came up with this beautiful, beautiful euphemism called the sunset.

Sunsets sound great! This is actually a picture of a sunset that I just took about two weeks ago in Fiji and I went “Ahhhh” when I was sitting on the beach. Isn’t this wonderful? Isn’t this beautiful? Let’s call killing software sunsetting. [laughter] That would be really nice. So the industry did and now whenever anyone kills a piece of software, theres like, we’re sunsetting this piece of software. All the users can sit on the beach and they can watch all their data fade away [laughter]. And then tomorrow there’s going to be a new sun where they can put in all their shit again. And they’re going to love it! They’re going to love it. It’s going to be beautiful.

Well, do you know, the only people who believe the sunset, that’s the people who call it the sunset. Any user who’s actually ever been through a period of sunset, nobody actually comes back and says, “Oh that was beautiful.” They come back and say, “Fuck! I put in years of work in this thing! I signed up for BaseCamp before you guys even launched it! I was on the mailing list! The mailing list, man! When you guys had 4000 people on your goddamn blog, I was there. And now you’re going to sunset me?”

No. So thankfully we never got to the guy that was yelling just before. We realized in advance that sunsetting would not be a great thing because we had been through some sunsets. We had used some products and they went “poof” and away. And it wasn’t fun and it wasn’t great and it didn’t make me think “Oh, yeah, it was so great and innovative because they ripped shit away and then they put some other stuff out and then they ripped that away and then they put out some other stuff and then they ripped that away!” Like, I don’t end up with positive thoughts of any company who sunsets shit. I end up thinking every single time, “Uggghhhhhh! Google!” right? Do you think any of the people who used Google Reader and put in all their fucking subscriptions into the thing went away thinking, “Yeah, it was time for that thing to go, man. [laughter] I was using it every day, but Google’s right, man. It’s just…It’s old! It had to go into the sunset. So now I’m just going to use Twitter and that’s going to be much better because then I’ll miss everything and like people will be yelling all the time and RSS was just old.”

Alright. So, the problem with sunsetting is, if you force users to switch to a new version, they’re not just going to jump along. They’re not just going to jump on your new sun and think everything is great. They’re going to go back in the store. You’re going to force them back into a buying mode and a buying decision where they need to think about “Hey, is BaseCamp actually the thing I want anymore? If we have to move all our crap over anyway, maybe I can just move it somewhere else. If I have to pack it all up into boxes and load it on the truck, I can just send that truck across town instead. That’s not a big hassle. The big hassle is to pack up all my shit. Whether it goes to BaseCamp again or it goes somewhere else, that’s not the big decision.”

So all of a sudden, people are back in the market. Remember that leaky bucket? The worst thing you want is people back in the market. When people have decided that they’ve bought your product and not some other product and they put in all their stuff into it, the vast majority of them, they’re no longer in the market. They don’t give two hoots about what anyone else does. They’re that stable water in the bucket that doesn’t leak out unless there’s something in their life or their business that changes. It’s not about you anymore. It’s not about your software anymore. But you can really quickly make it about you and about your software if you force them to change, if you force them to move over to something new.

And that is a really bad idea.

That is exactly what entails the worst strategic mistake ever. Taking your entire customer base and saying, “Hey, do you want to buy us again?”

Worst question. Never ask whether you want to buy us again. Never make people think about whether they should buy another piece of software. So, don’t, don’t do that. Like, if you’re going to take something away from this and “Oh yeah, let’s go home a rewrite our software and…” You have to honor your legacy. There’s just no other way. At least if you have a subscription business and at least if you care about keeping your customers around. You have to honor your legacy. You can’t just throw it all away. It’s all great to say, “We’re going to make a stingray chair.” I applaud you, I cheer you on. This is the point, partly, of this talk, is that everyone should be making their stingray chair. Everyone should be competing with their very best ideas when they have enough accumulation of very best ideas. I don’t say, like, rewrite your software every six months. Nobody has that many good ideas, sorry. Don’t. You have a limited supplies of very best ideas in your life, but when they come along, don’t let them pass by.

This is a Leica M3 camera. It came out in 1954 and Leica made it until 1967. Great camera, used by some of the greatest photographers ever. Wonderful piece of machinery. I love Leica. If you have a Leica M3 today, and it breaks, do you know what? You can send it to Leica A.G. and they will fix it. This is a product that’s been out of production for fifty years, made by a company that’s been around for more than a hundred. And they’ll still fix your Leica M3 from 1954? That is beautiful.

That is honoring your legacy.

That is exactly what you should be doing. Not jumping off your bridge, with growing old with people who only want to use film cameras forever. The Leica M3 is a classic, it’s a legacy and it’s beautiful, but if Leica was still only making the M3 today, how many customers do you think they would still have? There would not be a Leica A.G., right?

So this is this weird thing, that in order to be sustainable, in order to have a business that’s going to be around for the long term, to be able to honor it’s legacy, to be able to grow old with its customers, it also needs new customers. And this is the part that customers most of the time, they don’t see. Your existing customers if you propose a rewrite will say, “No! Don’t do that! Fix my goddamn bugs!” Because your software will always have bugs, there will always be more bugs and there will always be users saying, “Why are you playing around with this newfangled thing? Fix the thing you have! It’s still broken!” I’m sure there’s still bugs in that Leica M3. Still ways for the film to lock up or usability issues with how to put it in or whatever it is, or the rangefinder could be more precise, all these other things.

Okay. This is Ta-Da List. We launched this as a feature extraction of BaseCamp in 2005. There’s still I think a couple of thousand users using Ta-Da List right now. Well, not right now. On a monthly basis maybe. Anyway, people on Ta-Da List still have stuff in it. We have not cared, bothered, or done anything with this application since about 2006. It’s not a beautiful Leica M3, but for the people who use Ta-Da List and have important stuff in it, it’s really nice that we didn’t sunset it and throw it away. And do you know what? I still get occasionally an email from someone saying, “I love BaseCamp. I love everything you’re doing. I’m still using Ta-Da List.” And I go like, “Awww. That’s really sweet.”

The funny thing with, sort of, stop selling things but still honoring your legacy is that the cohorts you have still follow the natural trajectory. Just because you say, like, “Hey, no new people can sign up for Ta-Da List” the existing customers on Ta-Da List actually do not drop off at a faster rate. This surprised me. We’ve done this now with a couple of products where we’ve shut off new sign ups – can’t buy Ta-Da List any more, can’t buy Backpack any more, can’t buy Campfire anymore (I think) – and like nothing happened. Like the next day I thought like, “All right, they’re all going to pack up their shit and they’re all going to leave.” Nope. They bought the product, they liked the product, and when that natural day comes when they don’t want the product anymore, they’re going to leave. At the exactly the same rate that they would leave if it were still an active product.

So, we finally, I think this is from, this is from a year and a half ago or something, we actually had sign ups for Ta-Da Lists for like seven or eight years or something where we did not touch the product. The only thing we did was we kept it running, we made sure there were no security holes, sort of just the basics, no new features, no new nothing, and people kept signing up for it all these years after. For a very long time we were the number one Google hit for like “To-Do Lists”. I’m sure that helped a little bit.

Anyway, Jason wrote this note I think two years ago saying, “Hey, this is not a sunset. We are not killing this product. We’re just not giving it away to new people. It’s not our best ideas anymore and we don’t want that to represent the company for new customers.” And that’s fine. You know what we also did? We kept keeping it up to date. We kept running it. We kept operating it. And that’s the thing that people usually fear. If you’re going to have this collection of legacy then you’re going to have to keep spare parts around and people who know how to fix it and – Yes! What do you think happens when you send that Leica M3 to Leica in Germany? There’s a guy who knows how to fix Leica M3s. He doesn’t see M3s like twenty a week. But when one comes in he has to fix it. And you have to have spare parts and that’s the price of maintaining your legacy. It’s not free. Why would you expect it to be free? It’s valuable, so of course it’s not free. But it’s worth doing.

And I especially get that question when it comes to security, right? “Well if you have all this stuff and like, some big thing comes out and it’s a thing, and you have to deal with it.” Yeah, you do. It’s a thing and you have to deal with it. There’s lots of things you have to deal with. That’s business, and life and stuff, right? So don’t freak out over that. Don’t think you’re going to get something for nothing. Think that your legacy is valuable, so valuable that it’s worth investing in, it’s worth maintaining, it’s worth keeping around. But don’t let that keep you from building the stingray chair of your dreams. You can do both! Companies have done this since the beginning of time. This is a very new idea that products have to live forever and they just have to morph around and sort of turn into this other thing and never lose any features ever and never rearrange any tabs and be frozen in this static notion of what they are. That’s not how it have to be.

And the reason I’m interested in this topic now even though we did the rewrite in 2011 is we just did another rewrite.

We just rewrote the whole damn thing again and we’re putting out a brand new version – BaseCamp 3 – next month. And we’ve been working on that for a year and a half and you know what? It’s great. It’s a new stingray chair. I’m super-duper crazy excited about it because it’s really fun. Got to do a lot of cool things. Rails 5 is basically BaseCamp 3 extracted. All these interesting things that I would not be doing otherwise. I’m still interested in the business, what is that, can’t even do the math, 12 years on, since we started working on the first version of BaseCamp, because of that. Nobody’s going to stay interested in working on the same exact implementation of their ideas of fifteen years ago forever. It just doesn’t work out like that. But, if you continue to renew it, if you continue to let your best ideas have an outlet, in their pure form, you can have a new green field and you can have your beautiful little house on it and everything is wonderful.

So please, rewrite your damn software. Thank you. [applause]

Q&A

Patrick Foley: Yep. That last point you made about still being interested in the product after more than a decade. I had heard about DHH that, “Oh no, he’s only just interested in racing anymore.” Can you dig into that a little bit deeper? Was there a point where you said, “I don’t need to do this anymore, I’m not going to” and was that, you know, did this bring you back or did you, or was that rumor that I heard false, were you always really, no, always had the intention of keeping on with the software world as well?

David Heinemeier Hansson: I’ll say from 2008 until we made the decision to rewrite the software in 2011, I was not as engaged as I was afterwards, absolutely not. I worked less hours because I didn’t have to, checks were still coming in, everything was just great. I worked on other projects, I worked on other things, I picked up racing for the first time, I did a lot of other things.

But, I don’t see those things as being in contention. In fact, I am as passionate now about working on Rails and BaseCamp as I’ve ever been. This is, right now, the amount of code that I’ve written over the past year and a half, as much code as I’ve ever written in my career. And I love it. It’s awesome. And you know what, I can also have hobbies. It is not a binary thing. And I think that’s part of the whole unicorn rejection is this notion that to be fully engaged in your software or your business, that is the only thing you can think about and breathe 24/7. Bull-shit. I am the most productive, the most valuable, when I am well-rested, well-entertained, and diversified in my interests.

The times when I dig the deepest into something and just focus on that exclusively, it has a, that’s the dead part. It has a expiration time. If I push that very much further than not very long, then I do shitty work. I make poor decisions, I get too in love with the decisions that I did make, and I get too attached. I get too teddy-beary with the thing. I can’t rip off an arm or an ear if it needs a new arm or ear. So no, it’s not good. So yeah, I enjoy racing and I enjoy programming and I enjoy a lot of things. I enjoy reading, I enjoy ranting on Twitter, I mean, people can have more than one asset or facet of themselves and still do great work. So I think I’m doing the best work of my career, and I hope to continue to be able to do that because I hope to be able to continue to have good ideas and have an outlet for those good ideas.

And I think that’s exactly where we’re at now with BaseCamp. We’re version 3 now. The third time you do something you start thinking, “Okay, this is not going to be the last time,” right? I’m thinking there’s going to be a BaseCamp 4 and a 5 and a 6 and a 7. And if we’re going to last a hundred years, maybe a 25. And that’s great. I’m really looking forward to that.

Audience Question: So, I get the not sunsetting specific products when they die. What do you do as far as sunsetting versions and moving people to versions. Do you forcibly do that, do you let them stay?

David Heinemeier Hansson: That’s a great question. So, what do you do with the versions, do you force people over? When we launched the first rewrite of BaseCamp in 2011 we tried to do that. We tried to very hard nudge people over. And what we found was that that was a very bad idea. So, when we were forcing people to move over, very strongly encouraging them to do so, they moved over and they had a bad time. Things moved around, it wasn’t the same thing. All the reasons for why you shouldn’t, you know, switch things around on people within the same version, they were just triple true when we forced them to move versions. So no, we got disabused of that idea very quickly.

The new version of BaseCamp will not have an import feature. You cannot move your stuff over. What we do is, we set it up in such a way that you can keep your stuff forever and it’s not going to cost you anything. You can keep your stuff on the old version, you can keep your existing projects on the old version, don’t have to disrupt anything. That leaky bucket, we really learned from that. Don’t force your customers back in the market. It was only very recently that the new version of BaseCamp beat the old version of BaseCamp in terms of monthly revenue.

Like, for me, if people continue to pay me 50 bucks a month, what do I care what version they’re on? Whatever version makes you happy, man. It’s all good. As long as you keep sending your fifty bucks a month, you can be on whatever version you want. Just stay in BaseCamp, please.

Audience Question: So one of the concepts I liked from you guys was the concept that software can be considered done, that you’d kind of stay, you’d not grow old with the customers because they’d grow on to more complex software and you’d have the new guys coming in. So you’d fix a point in the history of their evolution and say “We’re solving that problem and it’s solved.” So does this mean you don’t believe in that anymore? That software isn’t done, that you’ve got to keep..

David Heinemeier Hansson: No, it means I doubled down on that belief. I doubled down that certain versions of software are done. That version 1 of BaseCamp is done. There’s not going to be anything else, it’s not going to have any new features and it’s great for what it is and it doesn’t need to be anything else. I think that’s exactly what happens and that’s when the rewrite time comes around, when we do realize that this software is done. Along this trajectory, along this paradigm, of UI or implementation or whatever that we pick for this version, when we’ve run it’s course on that, it’s done. And it’s time to get a new clean sheet, the act is over, we’re going to rip it up and we’re going to come up with a new act.

What’s not done, and that was perhaps my mistake, was that the mission of helping people make progress on projects together, how’s that ever going to be done? Like, is that, are we going to wake up tomorrow and mankind, “Yeah, projects. Eh, screw that. We’re not going to do any more stuff together. We’re just going to lay around.” Of course it isn’t. And that’s a very broad frame to paint within. And you can paint a lot of very beautiful pictures within that.

Audience Question: Great presentation, David. Really enjoyed it. After going through your previous rewrite and launch and now going into your next one, is there something you guys learned from that in terms of how you position it and message it to your customers and sort of improve that, that flow or that work process if you will?

David Heinemeier Hansson: Yep, I think the main thing we learned was to not force existing customers to move over. In fact, existing customers is not the target audience. We’re not writing BaseCamp 3 for people who are using BaseCamp 2. If they want to move over, that’s great and wonderful and they will be welcomed with open arms and we’ll give discounts and we’ll help them and we’ll do all sorts of things. But we’re selling to new people. Like, the people who show up at BaseCamp.com today, those are the people we intend BaseCamp 3 for. We have to compete with our very best ideas to be competitive for someone who do not have an affinity for BaseCamp today. Who do not care about our baggage and our legacy and so on and so forth. People today by and large are not buying a new Leica camera because they made the M3. It influences and it helps their brand and does all these other positive things, but at the end of the day you still have to make a new great product and it has to be on the market and people have to be able to buy it. So, making it for new customers.

The second thing I’d say is, even offering migration is very tough. When you change a table and you make it into a stingray, like, where do the plates go, right? Like, ahhh, you can kind of balance it on the side. Sometimes the data doesn’t even move over even if you are painting within the same frame, even if you have somewhat roughly the same features. So we got very quickly disabused of that.

The second thing I’d say is that originally we thought that oh BaseCamp next, maybe that is the final version, the eternal version, right? So, we didn’t even do version numbers. Do you know how confusing it is to figure out which MacBook you have? Oh, I have like a late 2013 MacBook Pro, like the one just before that came in December. Okay, that’s your version? Eek. I think Apple got it right when they just started “You have the iPhone 5 or the 6 or the 7.” So we have BaseCamp 3, and we’ll have BaseCamp 2, and we’ll have BaseCamp Classic. So, having explicit versions and giving people a chance to know what the hell version that they’re on, is a good thing. So, that’s two.

Matt, Know Your Company: Hey David, Matt here from Know Your Company. So I’m curious. Now knowing going forward that you’re going to be building BaseCamp 4, BaseCamp 5, etc. do you, does that change the way you make incremental improvements in say BaseCamp 3 or BaseCamp 2? For example, do you now when you do get really great big ideas, are you okay kind of pocketing them knowing that you’re going to build it into your next version instead of trying to forcing it in, force it into the current version?

David Heinemeier Hansson: Yes. [applause] [laughter]No, I mean really I think we’ve gotten away from the idea that we can redefine existing versions. You just can’t. Once people sign up for them and they learn them, and they figure them out, like, you’re stuck with that. So the BaseCamp 3 that’s going to launch, we’re going to tweak things. It’s not like you put it out and then it’s done. Not at all. We’re going to be working on this new version of BaseCamp for years to come because there’s still plenty of things that we want to fill in. But the frames are there. We’re now painting within the lines. And I do think it is liberating. It’s liberating to know that this does not have to be the final lines we’ve ever drawn, right? There will be a time, hopefully, when we get some new, good, great, ideas again. We don’t have them right now. If we had, they’d have gone into the product, right? So it’s not like we’re sitting on them while we’re launching this other thing. That’s not how it works. And usually it take a long time to build it up. You have to use something for a very long time to figure out why you don’t like certain aspects of it, right? So we have to live and love this version for years to come to figure out that now, okay, it’s time to do something else. But it’s still liberating. It means that the decisions we make now, I don’t have to live with them for the next hundred years. I actually thought that for a while. I thought that hey, whenever I make a decisions now, like, [snap] I own it, forever. Very nice to know that your decisions are not forever.

Audience Question: This is just sort of going back to version 1 and version 2, what do you see happening when some sort of base technology like a browser changes, like Google and Firefox recently don’t allow plugins anymore. You know, you have to move that technology. Does that mean version 1 is done at that point, or are you going to go back and retrofit it to a current technology. I’m just using the browser as an example.

David Heinemeier Hansson: Yep I think that’s a good question. I think the day that browsers can no longer render HTML and CSS and the sprinkles of Javascript we have, I’ll be dead and gone anyway so it won’t be my problem. I think that helps. We were never into Flash, ActiveX or any other fanciness. I think we were always into investing in the basics of things and I think HTML, exactly for that reason, developing for the web is the greatest thing ever. Developing for the web, actually, I think the web very might actually be an eternal platform. I think it might very well be that web pages from 2005 will render until the end of time. So, it makes it a wonderful platform to develop for and it reaffirms why I fucking hated Flash. [laughter]

Flash was exactly that platform, right? Owned by one vendor who eventually lost interest after they were mortally wounded by another vendor. That’s not a great place to be. That’s why I’m not actually, even though, like I use my mobile phone as much as anyone and more, and we have great mobile apps coming for the new versions of BaseCamp, thats not what has me passionate, right? Like, I love that we have it, I love that we do it, I love that I don’t have to do it, I love that we have talented people who care about that. I love developing for the web. The web to me is just this magic once in a century thing that just, I was just so lucky to be born at the time when that was just coming up. So…

Mark Littlewood: Fantastic. I know there are tons more questions and I’m sorry we’re not going to get a chance to take any more, but you can be around for

David Heinemeier Hansson: Well thank you very much. I’m here for the rest of the day today so come up and talk to me.

Mark Littlewood: Thank you very much, indeed. [applause]