Why the 'fail fast' approach is no longer effective for product teams ft. Allen Holub

[@joebowbeer]

I think "fail fast" originated as a coding practice, .e.g., checking preconditions on entry to a function and failing fast if they are not met. Later, this expression became associated with an iterative development process.

[@bernhardkrickl5197]

That's how we use "fail fast" at our company. Let the software detect errors as early as possible to cause the least amount of harm.

[@lolo101]

Different domain, different meaning :)

[@mariusg8824]

Yeah, I also learned the term as a defensive programming technique. Validate parameters as early as possible, don't hesitate to throw exceptions. A crash is favourable to weak diagnostics and data inconsistency. But that's craftsmanship on a very detailed level, I never got why and how this established as a company motto.

[@bulletbeatboxer]

We use it as a method to say, "Should this condition not be true, then surely nothing next will work. Stop here.". I.e a wrong configuration. For us doing mission critical things, the startup must be flawless. If it doesn't start up correctly, just stop.

[@Rick104547]

Interesting I have a completely different definition about fail fast which is stop the process (and do log) if any assumptions you made are no longer true (a parameter that is null which it shouldn't for instance)

[@Wesmadon]

Really well said. There's a lot in project management that folks don't take the time to understand, then create bad practices from buzz words and distortions.

[@perfectionbox]

"We don't know what we're doing, so just try one thing after another until something works."

[@Takyodor2]

Life summarised

[@Takyodor2]

To me "fail fast" means "build something that can be partially tested early, so that the ideas/architecture/core logic seems to work as intended, rather than finding out later when it's more costly to fix". This applies regardless of whether the idea is "far out there, small side-project idea" or "carefully specified, long term non-agile project". I thought it just meant that building stuff such that problems are visible as early as possible is more efficient. Huh.

[@schmetterling4477]

It can be. It avoids the pitfall of committing to the, often wrong, global structure too early. For the single developer or the small team that basically codes around King Arthur's round table and that goes for a beer after hours that's fine. But if you are in a multi-national team and the guys in a time zone 12 hours offset from your own decide to fail the libraries that your code depends on fast, then your goose is cooked.

[@logiciananimal]

Problem: "not working" comes in degrees.

[@Takyodor2]

So does "hell"

[@MrBemnet1]

Fail Fast has turned to we don't plan anything and we plough through

[@wadexyz]

Just some feedback, try not to make any noises while the person is giving the answer.

[@lordoisin]

"The original intent of the phrase makes sense" Misleading title...

[@codingcactus2203]

Subbed 👍

[@hgoebl]

The sound is miserabel

[@smallbluemachine]

They should fully unwrap the microphone from its factory packaging before using it.

[@colinmaharaj]

To prevent looking bad at the customer avoid failing fast at the customer and eat your own dog food

[@errrzarrr]

Anyways, Scrum is outdated.