At an F8 keynote, many years ago, Zuck admitted on stage that when you "move fast and break things" all the time, well, everything is constantly broken (duh) and it made it so hard for even their own engineers to maintain their own applications (which exist on a very large number of platforms) that he appreciated it must have been impossible for third parties to use their developer platform, and so he formally changed the motto to "move fast with stable infra".
The Fallacy of Move Fast and Break Things
61–70 of 99 posts
Re: The Fallacy of Move Fast and Break Things
#62The "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…
I always interpreted it as a recognition of different economic models between what we're taught in school ("software bugs will kill people! Remember the Therac-25! Remember the Patriot missile failure! Even if your bugs don't kill people, bugs found late in the lifecycle are super expensive (based on a single paper from 1990 or something)") and that of most saas applications. The academic attitude is appropriate for…
I've tried to treat my unimportant app developer career as being a stepping stone to something more important. Even if it's OK to release crap today, where will I be in 10 years time if that's what I have been practicing? I'd rather try to release bug-free software now, even if it causes friction where I work.
Re: The Fallacy of Move Fast and Break Things
#63Earlier quoted context omitted.
>But MFABT is different as a formulation: it articulates broken things an imperative rather than a side effect No, it only looks like a desirable "imperative" if you read it with a hyper-literal interpretation . MZ's aphorism is just using the rhetorical device of taking something undesirable and acknowledging it. Yes, the literal words might appear like an "imperative command" but the underlying meaning of the messa…
> No, it only looks like a desirable "imperative" if you read it with a hyper-literal interpretation. "Break things" is objectively an imperative. There's no hyper-literal or otherwise careful parsing necessary to arrive at that realization. It's the default. Careful thinking is actually what you need to arrive at the more useful non-literal understanding. And unfortunately the phrase itself doesn't encourage that. S…
>"Break things" is objectively an imperative.
I wrote desirable imperative.
You are focusing on grammar (objective interpretation). I was talking about the meaning ("imperative" as synonym for "importance"[1] instead of grammar).
Likewise, "go get more rejections" is also an imperative (via objective lens of pedantic grammar categorization) ... but that's not what the underlying message means.
>MFABT is not an optimal expression. There are better ones.
It may have been fine as an internal mantra within the walls of Facebook when it was a smaller private company. The engineers would know what it really meant. But then MZ publicized it in an investor letter before the IPO which opens itself to misinterpretation by the outside world like journalists, bloggers, etc.
Re: The Fallacy of Move Fast and Break Things
#64"Move fast and break things"--said no carpenter, ever. Imagine if doctors, engineers, plumbers, electricians, and all the other real world folks we depend on decided this was a good way to operate. Would you drive across a bridge knowing that was the motto of the people who designed and built it?
"Measure twice, cut once" I think is the saying carpenters use.
And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."
Re: The Fallacy of Move Fast and Break Things
#65"Move fast and break things"--said no carpenter, ever. Imagine if doctors, engineers, plumbers, electricians, and all the other real world folks we depend on decided this was a good way to operate. Would you drive across a bridge knowing that was the motto of the people who designed and built it?
>"Move fast and break things"--said no carpenter, ever. Worst analogy ever. If we had GIT for woodworking you would see productivity skyrocket. But you can't restore wood like that. You can't restore pipes, wires, structures like that. Code.. you can. So get out of here with your analogy. I can move at a very fast paced coding new ideas at times, or implementing random stuff knowing I will probably break stuff. But y…
And do you make your users suffer your broken stuff?
Re: The Fallacy of Move Fast and Break Things
#66The "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…
> Should programmers[1] at NASA "move fast & break things"?!? Of course not.
I have a problem with my coworkers making the claim that it is actually safer to move fast. If you're uncertain about your software, release it now, rather than later because you'll become even more uncertain as time goes on.
Re: The Fallacy of Move Fast and Break Things
#67"Move fast and break things"--said no carpenter, ever. Imagine if doctors, engineers, plumbers, electricians, and all the other real world folks we depend on decided this was a good way to operate. Would you drive across a bridge knowing that was the motto of the people who designed and built it?
>"Move fast and break things"--said no carpenter, ever. Worst analogy ever. If we had GIT for woodworking you would see productivity skyrocket. But you can't restore wood like that. You can't restore pipes, wires, structures like that. Code.. you can. So get out of here with your analogy. I can move at a very fast paced coding new ideas at times, or implementing random stuff knowing I will probably break stuff. But y…
Can you fix data?
Re: The Fallacy of Move Fast and Break Things
#68"Move fast and break things"--said no carpenter, ever. Imagine if doctors, engineers, plumbers, electricians, and all the other real world folks we depend on decided this was a good way to operate. Would you drive across a bridge knowing that was the motto of the people who designed and built it?
Thing is, they do, but not in the ways you would expect. Cadavers on medical schools. Wind tunnel modeling. Computer-aided designs. The main difference to those is that the software industry can indulge on testing its own assets with little to no cost, and especially if that does not impact your ability to generate revenue.
Right, because who cares if it's broken crap as long as it's generating revenue.
Re: The Fallacy of Move Fast and Break Things
#69The "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…
Then maybe they should change it to, "Move fast and break things for yourself so that you can move fast and still not break anything for your customer."
Re: The Fallacy of Move Fast and Break Things
#70The "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…
Then maybe they should change it to, "Move fast and break things for yourself so that you can move fast and still not break anything for your customer."
Software development is a team sport, and if each member of a basketball team practices exclusively in their driveway on their own, when game day comes around they won't be able to work as a group. I think that this team dynamic needs to be practiced as well. And there will be a lot of team failure before there is team cohesion and effectiveness.