My notes from DHH’s talk “REWRITE!”

In 2016, DHH from Basecamp gave a talk entitled “Rewrite!”. You can find the video and the transcript here. But since they are both a bit long, I am going to share my notes with you as a shorter alternative.

Executive summary: When the technical debt or legacy features start to drag down development, stop trying to refactor your old product — just stop building on it. Freeze its development, but keep it available for those who still want to use it. Then you can focus on writing a fresh new codebase with no legacy concerns! (Of course, you can reuse useful libraries if they are suitably decoupled.)

Disclaimer: These notes are a little rough, and when I tried to clean them up they only got longer. Some of what follows are my own ideas, some are direct quotes from the transcript, or paraphrasing.

History of project management

The old “engineering-style” methods of project management (e.g. waterfall) often failed when clients didn’t like the software that was delivered.

So developers moved to agile methodologies, embracing the idea of software that adapts and changes.

That makes good sense when creating a new product, but long-time users of established products don’t want change!

Removing something will make some users sad. Adding something will make the app bloated. Changing something will anger old users.

“You just can’t redefine existing versions. Once people sign up for them and they learn them, and they figure them out, like, you’re stuck with that.”

So we end up being stuck with all the decisions we made that have gone into that product, sometimes decisions we made years earlier.

Dream

DHH wanted to make something new and beautiful. He wondered if he could adapt his existing software into this new thing. (Big functional table to simple elegant chair.)

Joel Spolsky says a rewrite is a bad idea. (E.g. it killed Netscape.) All that code, all those decisions, are there for a reason (e.g. unexpected edge-cases). If you throw out the code, you must revisit all those problems. So you are supposed to keep your old code, and refactor slowly.

But DHH wants to create something new, perhaps solving old problems but in a new way. He can’t change his old product into his new idea. His old product is the wrong shape. And change will disrupt too many users.

So sometimes we do need to rewrite!

Reasons not to rewrite?

There might be good reasons why not to rewrite. But you won’t find them here. DHH was arguing for rewriting in this case!

From the business point of view, it doesn’t seem logical to make a change when everything is going well. But beware of stagnation! When the money is coming in, use it for the next stage. “Make hay while the sun shines.” Don’t wait until it’s too late, until your users are pouring out of “your bucket” and into other services.

Warning: The users you hear from are your old/existing users who love your product. You don’t hear from prospective users. They take a quick look at your website and if they don’t find the ideas good enough, they leave. So the feedback you get is always skewed against innovation!

How to rewrite?

The comedian Louis CK said to challenge himself to do good work, he throws out his old act every year.

Forget the old product. (At least mentally. You could reuse some of the old code, if it is neatly separated.)

How to do the rewrite? Get abstract! Abandon fixed ideas. Put your previous product out of your mind.

Go back to the vision. Where do you want to be? What do you want to achieve? How do you think you can help people?

After the rewrite

So BaseCamp did that, and they did a rewrite (BaseCamp version 2). Signups doubled when it was released. Lots of prospective users who had been turning away now didn’t!

So should we “sunset” the old product? NO! Do not do that. We don’t want users to leave our bucket and go shopping around. We want to keep them in our bucket. They have invested in our product, they will only stay if we keep supporting their decision!

Keep supporting your old product, but freeze development. Keep it running, and do security fixes (but maybe not bug fixes). If it’s useful to people, then let them keep using it.

(E.g. The company Leica manufactured the Leica M3 camera between 1954 and 1967. But even now in 2015, if you send it back to them for repair, they will repair it! That’s good customer service!)

BaseCamp did freeze new signups for the old product. But don’t expect that to affect existing users. Even if you do that, existing users will drop off at exactly the same rate as if it was an active product. They drop it when it’s no longer useful for them, not when you tell them to.

Invite existing users to use the new version (with discounts / incentives).

Provide data migration where possible. But accept that maybe not all the data can realistically be migrated. Your new product may be a different shape from your old one.

“Existing customers are not the target audience. We’re not writing BaseCamp 3 for people who are using BaseCamp 2.”

Future

Audience question: “If you know you’re going to rewrite, do you pocket ideas for the future version?”

Yes and no. You can keep painting within the frames of the existing version.

And new ideas don’t always come so quickly. They come out of using the existing product. “You have to use something for a very long time to figure out why you don’t like certain aspects of it, right?”

General

Focus on your best ideas: “You have a limited supply of very best ideas in your life. When they come along, don’t let them pass by.”

Enjoy life: “Reject the 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. BS! I am the most productive, the most valuable, when I am well-rested, well-entertained, and diversified in my interests.”

Takeaway

Rewriting is a great relief from historical burdens: “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.”

(In reality, you may have to support old decisions forever, but at least you can move your focus onto something new.)

This write up was originally posted on LinkedIn.