How do you keep adding new features quickly?

Hey {{ subscriber.first_name | default: “there” }}, what are you working on today?

I’ve been adding features to a few projects that people really depend on. And there’s something I’ve been thinking a lot about.

How do you make big, creative, meaningful changes to your apps?

The fastest way would be to just make the change. Forget about the other code and features in your app. Tear out the old code, check in the new code. Move fast, break things.

When you’re starting out with a new app, “just make the change” is extremely effective. You don’t have a bunch of users to annoy when your app doesn’t work. You don’t have a ton of code, your new stuff doesn’t really affect your old stuff. Breaking things is the last thing you’re worried about.

And it works… for a while.

Eventually, if you’re lucky, your app gets used. And once you have real customers, your work is riskier – it’s hard to make big changes that have a big impact.

You can’t move fast and break things, because now you’re breaking your users, you’re breaking your team, you’re breaking yourself. Your code is a mess, and you can’t keep the whole system in your head anymore.

And so, because you moved fast, you now have to move slow. Be more cautious. Spend more time testing. Start to fear big changes.

And that’s a shame, because big changes are the fun ones, and the ones that make a real difference.

So how do you make important changes faster? Tests will help. More process might help. Writing better code might help.

But there’s another way.

In refactoring, you change structure without changing behavior. You take small steps, each unnoticeable to the outside world. And with those small steps, you shape your codebase into something that makes bigger changes smaller.

That gives you the courage to make bigger changes, because they stop being so big. You move in small ways to move in big ways.

There’s another pattern. Have you ever used a feature toggle, or shipped a new version of a feature alongside an older one?

This is powerful. Because the old version is still around, you can be more ambitious in the new version. You can invite people into the new world, instead of forcing them into it. And because there’s less risk, you’re more likely to actually make that big change.

There are a few different ways you’ll find safety and courage when creating software.

You can try to prevent problems. Automated testing, testing by hand, and enforced process can all help.

You could also reduce the impact of a bad change. How easy is it for someone to get work done, even if something goes wrong? How easy is it to reverse something that’s not working out?

When you reduce the impact of mistakes, it’s especially powerful. You can bring the “move fast and break things” mindset back into more mature apps – this time, without the drawback of actually breaking things.

You can make big, important, creative changes, without fear. And that’s especially fun.

Thanks for reading, and have an awesome day!

P.S. Are you going to RailsConf 2017? If you are, I hope I’ll see you there! I’m giving a talk, called A Deep Dive Into Sessions, to help you understand one of the most important Rails features.

If you’re planning to go, hit reply, or get in touch with me on Twitter – I’d love to meet you.