The Fallacy of Move Fast and Break Things
launchdarkly.com
The Fallacy of Move Fast and Break Things
1–10 of 99 posts
Re: The Fallacy of Move Fast and Break Things
#2In summary; don't move so fast that you stumble, and be wary of what you break.
I think a better one would be "don't run your company based on aphorisms".
Re: The Fallacy of Move Fast and Break Things
#3In summary; don't move so fast that you stumble, and be wary of what you break. I think a better one would be "don't run your company based on aphorisms".
Also, make sure you are running in the right direction. Ideally before moving fast.
Re: The Fallacy of Move Fast and Break Things
#4Move fast and break things has always been more marketing than real ethos. It's an obviously obtuse thing to say to signal people you're an asshole savant (whilst writing mediocre php in your bedroom). I don't know why people bother with it so much.
People act as if because "Move fast" is a good thing, it has anything to do with "Break things". Does everyone at facebook sprint around the office and break limbs when they bump into each other around a blind corner? No, because they're not morons.
Re: The Fallacy of Move Fast and Break Things
#5It is not a motto, it is an anti-pattern.
When you are still prototyping and have not found product-market fit, it might work. (And that quote comes from the early days of Facebook, when it was still morphing into its final form.)
Once you have established yourself as a viable product, found your fit, and have paying customers, "break things" becomes a path to poor service.
Re: The Fallacy of Move Fast and Break Things
#6Original article: https://devops.com/the-fallacy-of-move-fast-and-break-things...
Re: The Fallacy of Move Fast and Break Things
#7Great article.
Move Fast and Break Things always meant “and don’t be afraid that you might accidentally break things, because you eventually will and you should just fix them if you do”.
The saying isn’t itself a fallacy but doing the moving fast part without adequate resources to do the fixing part is indeed reckless.
Don’t push on a Friday night. Don’t push without metrics on error rates. Talk to your team. Append instead of overwrite. ..etc.
Re: The Fallacy of Move Fast and Break Things
#8Great article. Move Fast and Break Things always meant “and don’t be afraid that you might accidentally break things, because you eventually will and you should just fix them if you do”. The saying isn’t itself a fallacy but doing the moving fast part without adequate resources to do the fixing part is indeed reckless. Don’t push on a Friday night. Don’t push without metrics on error rates. Talk to your team. Append…
Agreed. I always saw this as an extension of "fail fast" -- or an encouragement to experiment (even when those experiments aren't as successful as you'd like).
Sometimes, teams get stuck in 'analysis paralysis' -- and this was meant to be a type of antidote.
To the folks that say this is a type of anti-pattern, I say: Either you haven't seen this implemented correctly (it helps if you have kids that you want to encourage to explore) or "There is more than one right way to be creative".
Re: The Fallacy of Move Fast and Break Things
#9The HN crowd (and related ecosystems) have been using this as a mantra for a decade or more now. Interesting to see it only took worldwide attention and derision of this "model" to make us even consider it as a fallacy.
To me it further confirms it - don't trust either the industry, or the people in it.
Re: The Fallacy of Move Fast and Break Things
#10Great article. Move Fast and Break Things always meant “and don’t be afraid that you might accidentally break things, because you eventually will and you should just fix them if you do”. The saying isn’t itself a fallacy but doing the moving fast part without adequate resources to do the fixing part is indeed reckless. Don’t push on a Friday night. Don’t push without metrics on error rates. Talk to your team. Append…
Adding: Hire and retain enough experienced staff. Too often these things boil down to one or two engineers shouldering the entire burden of keeping these systems online.