💠Fail Fast, Fix Fast
Applying the Fail Fast mentality to architectural decisions in the field of programming.
I think it finally clicked what fail fast in the agile context is about. It dawned upon me when I thought about a particular mistake I made when laying the foundations for a big Vue project. Of course, I made a lot of errors, but two of them are severe. And one of those two I'm currently thinking hard about fixing.
Disclaimer: I look at fail fast from the perspective of a programmer. Mainly it's discussed from a product point of view, meaning fail fast with new product ideas to find out what users really want. But it also works in the context of architectural decisions in our codebases.
I understood that fail fast means that we acknowledge and fix our mistakes at least as fast as we make them. The longer we don't fix our errors, the longer they drag us down. And the greater our fear of making new mistakes, because we see how dire the consequences can be. But programming is hard. If we are not willing to make mistakes, we will hardly make any progress.
On the other hand, if we admit our mistakes and fix them as soon as possible, we learn that it is not so bad when we make mistakes because we can redeem ourselves by fixing them. Especially in larger teams, it is essential to take responsibility. We can't wait until somebody else fixes our mistakes.
How to Fail Fast
Admit mistakes and wrong decisions as soon as possible.
Make fixing architectural errors from the past a top priority.
Don't let your own past mistakes drag you down: take responsibility, fix them and learn from them.
Acknowledge that making mistakes is part of making progress.
The first point is crucial: more often than not, admitting a particular mistake is harder than actually fixing it.
It's Not as Much Work as You Think
With fundamental technological or architectural decisions, it often seems like the only way to fix the mistakes from the past is to put a lot of work into it. But often, that's not the case, and you can make significant progress in 1-3 working days if you focus on it. And almost always, you can get there in small steps, too.
Be ready to make mistakes, admit them, and fix them as soon as possible. Don't make it a big project, like a refactoring sprint, but just do it. If you can do it in 1-3 days, do it immediately. If not, do it step by step (Branch by Abstraction) but start as soon as possible.