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
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.
Learn how great SaaS & software companies are run
We produce exceptional conferences & content that will help you build better products & companies.
Join our friendly list for event updates, ideas & inspiration.
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]
Learn how great SaaS & software companies are run
We produce exceptional conferences & content that will help you build better products & companies.
Join our friendly list for event updates, ideas & inspiration.
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]
Learn how great SaaS & software companies are run
We produce exceptional conferences & content that will help you build better products & companies.
Join our friendly list for event updates, ideas & inspiration.