When 'Fail Fast' Fails

Hello everyone,

Today, let's dive into the idea of failure - specifically, the celebrated mantra “Fail Fast” !

Silicon Valley's favorite mantra "fail fast" promises rapid learning and efficient iteration. It’s great until it collides with complex, long-running (tech) projects. I'm sure many of you have experienced this at some point in your career while working on tech projects.

The Promise vs. The Reality

We've all heard it in standup meetings: "Let's just ship an MVP and iterate." This approach works beautifully for features like UI changes, internal APIs or isolated microservices. But consider these scenarios:

• You're rebuilding your core authentication system

• You're migrating a decade-old monolith to microservices

• You're implementing a new distributed database architecture

• You're overhauling your entire CI/CD pipeline

These kinda projects aren’t suitable for “roll back if it fails.” Each requires months of careful planning, coordination with multiple teams. It sometimes represents a one-way door decision.

Where Fail Fast... Fails

Over-Reliance on Early Testing:

Testing early is actually good. But in large projects, over-focus on initial tests can lead to misinformed decisions, especially when early data doesn’t account for complex dependencies that emerge later. (those edge cases…you know)

Rushing into Production:

The "just ship it" mentality often leads to technical debt when applied to long-term projects. Shortcuts taken in the name of “fast” can introduce problems or create layers of workarounds that take months or even years to untangle.

Underestimating Real-World Impact:

Unlike smaller, isolated projects, long-term systems don’t operate in a vacuum. A minor disruption in one part of the system can cascade, causing more significant and expensive issues down the line.

Rethinking Failure

Instead of blindly applying "fail fast," successful teams are adopting a more nuanced approach:

Use “Micro-Failures” Within Safe Boundaries

Break the project into lower-risk sections. E.g. testing in sandbox environments, isolating smaller components for experimentation or creating POCs (proof-of-concept) versions.

Simulation over Production

Use rigorous simulations to model failures before they reach production. This “fail fast on paper” approach is crucial for complex projects, allowing teams to learn without jeopardizing real users or systems.

Redefine What “Success” Looks Like

Long-term projects require redefining success: it’s not just about speed, but also stability and resilience. Instead of quick wins, measure success by reliability, adherence to strategic goals and even overall system health.

The Takeaway

The real art lies not in failing fast, but in knowing when to apply rapid iteration versus strategic progression. Sometimes, boldest move (specifically for long-haul initiatives) is to slow down and acknowledge that, the challenge isn’t just in failing fast; it’s in failing wisely.

I’d love to hear your experiences. Have you encountered the contradictions of “fail fast” in your work? Join the conversation on LinkedIn and 𝕏  

And if you find this newsletter useful and you want to contribute to sustain and evolve it, please think to "buy a coffee" 

Thanks for reading,
Kelvin
TechParadox.dev