Why I prefer to fail forward?

I fail a lot. I'm not bragging or lamenting myself. Just a fact. I was also trained as a developer and engineer where having a rollback plan was important and the thing to do if something went wrong.

But over the years, when something happened and I deployed a bad version of a software or wrote a stupid article here on the site I rarely roll back to a "safe place". Instead I tried to solve the problem and ship something else. So I always pushed forward instead of going back to a "safe space". Failing forward is not a new concept. There are hundreds of books and articles about this, so I'm not claiming anything about the concept. Just telling my experience.

I want to show you why "failing forward" is the way to go, but your circumstances will be different so please consider this as a concept or mindset and not something that fixes all the problems. That doesn't exist.

Let's check some examples to understand the concept.

Musicians & Chefs

Think about musicians and how they play. If they make a mistake they don't stop the music and start again. They continue pushing forward, learn where they've made a mistake and fix it later. The same can't be said for chefs where a mistake sometimes implies starting over, otherwise they would serve crap food to the clients and that's not ok.

I want to highlight these 2 cases because we always need to adapt to our circumstances. If you can, proceed until the end and fix along the way.

It's dangerous to continue to start over or to go back to a "safe path". It makes you risk averse. I'm not saying that you should not have a security checkpoint (backups are important especially before they are needed), but what I'm saying is that preparing as best as possible and adapting along the way brings you an improvement mindset and not a "run back to safety" mindset.

If things go wrong, that's life! No big deal. Live and learn.

Software & Site

In software there's the notion of versions. We deploy a new piece of software and if something goes wrong we roll back. For some it's necessary but I would argue that it's not always in your best interest. Look at Apple over the years. They've made horrible choices in iOS and macOS, shipping things that were absolutely bad for the users. In recent history the 26 deployment made my phone blow up with family members asking "how can I revert back to the previous version" or "how do I fix X" or "why didn't you tell me". But that doesn't mean that Apple scrapped the deployment and rolled back to the previous version. They learned and improved and continued to ship things, even with unhappy people.

I would argue that this is super useful. To not roll back and listen to what people have to say, learn and then fix things. Better mindset, better positive cycle and better results in the end.

Imagine that they go back and then ship a v2 that is as bad as the previous one. And then go back again. They will look unprofessional and that they don't know what they are doing. Small improvements over time compound better while adjusting along the way, than always running to safety when something goes wrong or not according to plan.

This mindset helped me a lot over the years. I ship, check, improve, and ship again. The site is a good reflection of this. I've had dozens of things that I shipped and didn't work. Articles and sections that I started and people didn't like them or got nearly zero view. Bugs in the site. Stuff that didn't even work.

I didn't delete the articles and "rolled back" to a safe state. I kept them there and continued to improve. Some of you (and I'm super thankful for that) email me things that I get wrong on the site. Some of them are embarrassing, but hey, I fix them, thank the people and move on.

Speaking of embarrassment.

Embarrassment is overrated

Another thing that helped me over time is figuring out that embarrassment is overrated. Recently I started looking at the older articles that I wrote and they are indeed embarrassing. Especially when I check the analytics and see how many people read them. How many people think that I'm an idiot for publishing things that are not correct.

It happens to all of us. I understand that I made mistakes, but I also understand that this is how we learn. Doing, learning and then looking back and improving.

You will see more and more articles being updated over time with new information, better English and issues fixed. It's a good sign. It means that I learned. I could have deleted the articles and written new ones and hide the mistakes from the past.

I'm not embarrassed by those mistakes, not at all. It's a learning opportunity and I'm happy that after a few years I can look and actually see points of improvement. If I didn't then it would be a bad sign.

Time & Boats

Another consideration is time. When something goes wrong it's possible that we will need to spend some time rolling back to the previous stable point and that time could have been used to fix the problem in the first place. So you're wasting time to go back to the same place as before while you could have used that time to fix things and ship again. Not always but sometimes, so keep this in mind.

It's not nice for people to have crashing apps and seeing mistakes, but in my opinion it's good to develop the mindset that we should prepare things before we deploy them properly so that we minimize mistakes and potential issues.

This always reminds me of the "Burn the boats strategy", where there's only a path forward and if you run away you won't gain anything. Or if you don't have a way to go back then moving forward is the only possible thing to do.

Time could be on your side, but also training you to think about things carefully is important so that you don't have the mistakes in the first place.

Caveats

Like everything in life there are exceptions and no rule fits all. Like I mentioned before a chef can't fail forward. There are other cases in your own world that you can't afford this and you need to roll back to a place of safety. In software, if you ship something with a security issue, you need to quickly roll back, fix it and then release another version. If you think about a service that it's good but creates harm to people, then taking it out quickly is the best possible solution.

What I'm saying is not that this is a 100% "always-do" rule. It's something that can be considered and thought through and it could be a nice mindset to have. Go forward and learn and go back when needed.

Always look back and learn though. It's important to learn from mistakes as much as possible so that you don't repeat them.

Also I'm absolutely not telling you that you should "go fast and break things". Shipping things with care is important. Testing before is important. Checking for legal and safety requirements is important. But mistakes happen but if you did your job properly then you can have enough information to fix a problem and then ship something that will fix it.

Final Thoughts

Failing forward isn't about being reckless. It's about preparing well, then trusting yourself to fix things as you go instead of always running back to safety. It won't fit every situation, but as a mindset it has served me well: ship, learn, improve, and keep moving.

Give it a try and see if it suits the way you work.

Photo by Semen Machin on Unsplash