The Fallacy of Move Fast and Break Things
11–20 of 99 posts
Re: The Fallacy of Move Fast and Break Things
#12Re: The Fallacy of Move Fast and Break Things
#13 What are the consequences when you try to move fast and not just break things, but fail?
- It takes longer to resolve incidents.
- You lose customer confidence and sales.
- Employees burn out, and you have a high turnover rate.
The main idea behind the approach is making sure that you can move fast and break things whilst minimizing those consequences. It means absolutely nothing if you just let things break; that would be even unethical.- Taking longer to resolve incidents will allow you to anticipate minor issues that could add up during a worst-case scenario, which is a valuable thing.
- Impact on customer confidence is less critical in earlier stages, when you are not expected to make a profit. Once again, these minor impacts on it will, ideally, bring attention to things that matter.
- Employee burn out is uncorrelated to this approach. It is all about having the right policies in place, replacing blaming by accountability and treating other people with due respect.
Re: The Fallacy of Move Fast and Break Things
#14- "A ship in harbor is safe but that's not what ships are made for."
- "If I've made more shots than you, it's because I've _missed_ more shots than you." -- variations of this from Michael Jordan, Wayne Gretzky, other athletes
- "All great writers got better by writing a lot of _bad_ sentences."
- "If you want to learn how to ride a bike, roller skate, ski, snowboard, etc you're going to have to _fall down_ a lot."
All of them are trying to be provocative in the same way: expect repeated failures when experimenting/exploring what success looks like.
So MFABT when compared to variations of previous quotes is pretty standard advice. Nevertheless, everybody likes to poke holes in it because it came from a source a lot of people don't like: Mark Zuckerberg & Facebook.
Should programmers[1] at NASA "move fast & break things"?!? Of course not. I know what the original context of MFABT was about so it doesn't apply to NASA.
[1] https://www.fastcompany.com/28121/they-write-right-stuff
Re: The Fallacy of Move Fast and Break Things
#15So quite often, I guess.
I do think "move fast and break things" has a place, but that place is mostly limited to so-called transcendental problems: situations where the status quo don't work and we need to try something outside of the established solution space. It's kind of comparable to the over-use of brainstorming; quite often brainstorming is not going to help you find the solution to a problem.
Re: The Fallacy of Move Fast and Break Things
#16Move slow, break things anyway, disable tests to hide it.
Yeah, I've quit.
Re: The Fallacy of Move Fast and Break Things
#17The "move fast and break things" is just a web app version of previous sayings in other domains: - "A ship in harbor is safe but that's not what ships are made for." - "If I've made more shots than you, it's because I've _missed_ more shots than you." -- variations of this from Michael Jordan, Wayne Gretzky, other athletes - "All great writers got better by writing a lot of _bad_ sentences." - "If you want to learn h…
Most of the criticism of "move fast and break things" is word thinking. The move fast part includes "rate of correction".
Re: The Fallacy of Move Fast and Break Things
#18My current company seems to apply the following variation of the motto: Move slow, break things anyway, disable tests to hide it. Yeah, I've quit.
Re: The Fallacy of Move Fast and Break Things
#19My current company seems to apply the following variation of the motto: Move slow, break things anyway, disable tests to hide it. Yeah, I've quit.
Ha, amateurs - my last company never wrote any tests in the first place.
Re: The Fallacy of Move Fast and Break Things
#20My current company seems to apply the following variation of the motto: Move slow, break things anyway, disable tests to hide it. Yeah, I've quit.
Having the wrong things broken is a great way to move slow . Heavily manual (so, insufficiently documented) deployment processes, difficult, manual correctness testing, slow feedback loops in development, that kind of thing. Poor rollback planning.