5 ms·

The "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

by jasode 7y ago

The "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 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 https://www.fastcompany.com/28121/they-write-right-stuff

sremani 7y ago
I think it comes down to volume and rate of corrections. You will inevitably make mistakes in many endeavors and most mistakes are not fatal, but while making mistakes the rate of correction during this time puts you on the right path. Most of the criticism of "move fast and break things" is word thinking. The move fast part includes "rate of correction".
- lnenad 7y ago
  It's also the size of the corrections, doing daily builds probably means you've changed a small piece of functionality and even if stuff breaks it's usually a quick fix, whereas doing them monthly/bimonthly carries a much higher risk of completely breaking stuff and is much harder to fix.
- braythwayt 7y ago
  With respect... I would say that a great deal of the criticism I’ve seen is of behaviour that can be summarized as, “Move fast and break things for other people. But if we’re achieving our objectives, no need to correct.” It is not fair to characterize all “Move fast and break things” as falling into this egocentric bucket, but My anecdotal experience is that this is what attracts the most criticism.
rjkennedy98 7y ago
My favorite is by Samuel Beckett: > Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.
- lioeters 7y ago
  "Fail better." That is so good, thanks for the quote!
lnenad 7y ago
Yeah, like many things in our sphere things are taken literally (I am guessing since it's always easy to criticize) and are taken like they're a global pattern every programmer in the world should follow (same goes with microservices, k8s etc...).
deleted 7y ago
[deleted]
wwweston 7y ago
I more or less like FB as an application (and I have no idea whether I should like Zuckerberg or not). But MFABT is different as a formulation: it articulates broken things an imperative rather than a side effect that needs to be persevered through. There's also context to it that matters -- everything from the great documentation diaspora from a decade back where they blew away a developer wiki that represented years of community effort to describe how to use the various APIs without having anything remotely like an adequate replacement, to changes a few months ago which temporarily had access to the "Friends Lists" features unavailable which made managing privacy settings more difficult. There's a lot of things FB does right too, but when looking at blunders, it's easy to have the catchy phrase come to mind and wonder if maaaybe someone overconfidently strode forward MFABT in mind when more caution might have been warranted. You can't make an omelete without breaking a few eggs, as they say, but if you say that often enough, you start to get some people who think cracking a few open means breakfast is ready.
- jasode 7y ago
  >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 message is actually "failures are the path to success". The rhetorical language is a form of reverse-pyschology. Another similar example is salespeople or romantic suitors trying to get "yes" instead of "no" from prospects. The "no" is undesirable but rejections are inevitable in the process. Thus, one reverse-psychology approach is to frame it as, "How many _rejections_ did you get today? Only 10? Go make some more phone calls until you get 50 more rejections!" It still doesn't mean rejections are the real goal. We're just humans playing with language to get past the fear of rejections holding us back.
  - wwweston 7y ago
    > 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. Something like "Move fast, even if there's risks" or "Prefer momentum over risk aversion" would be the face-value formulation. > We're just humans playing with language And being played with by language. If language is powerful enough to orient someone on the benefits of preferring momentum over risk aversion, it's powerful enough to distract from the threshold where there's inadequate anticipation of consequences. Any given formulation may do one job better than another. MFABT is not an optimal expression. There are better ones.
apinstein 7y ago
There is an important distinction between MFABT and these other examples. In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. People make better decisions about the risks to take when they have to deal with the consequences. With MFABT the party doing the breaking isn’t often the one suffering from the breakage and that drastically changes the system dynamics of such a policy. It has a huge tragedy of the commons dynamic to it. I have seen so many companies and products end up getting stuck treading water due to these dynamics. It only even begins to be workable if you a) have almost no users so breaking is of little consequence or b) you have so much money coming in due to moving fast that you can pay for the cleanup. Always be aware of the primary and secondary effects of the system you implement.
- jasode 7y ago
  >In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. If a fishing ship goes out to sea and fails to catch enough fish or is wrecked because of a storm, it affects the families of the crew and everyone else who depended on them. If Michael Jordan fails and misses the game-winning shot, it affects his whole team. If it's losing a playoff elimination game, it affects the workers at the sports arena because they don't the get the income from extra games. > With MFABT the party doing the breaking isn’t often the one suffering from the breakage I don't know about every company that's (misusing) MFABT but with Facebook, it was their mantra before 2012 when they were not making any profits and trying to survive while competing against the bigger website, Myspace. Their software engineers could have conceivably broken their website so badly that FB goes out of business. That's what happened with Knight Capital when they misconfigured a server and lost $450 million. MZ's aphorism is just a twist on a common observation about making progress. He expanded on it in an interview: >We've optimized so much of our culture around just making it so that people can come and build things quickly. Whether it's everything from having the right tools in the right development environment to build things quickly, to nightly code pushes, hiring the best people who have a bias toward just pushing things very quickly, very entrepreneurial. The whole culture is tuned around that. And I think there's probably something in that for other entrepreneurs to learn which is that making mistakes is okay. At the end of the day, the goal of building something is to build something, not to not make mistakes. [1] He actually does not want a broken Facebook system. But he also knows that if there are no mistakes, it means the team is not bold enough with adding features. Yes, they could die from a broken code deployment to production servers. But they'll also die if Myspace or Google+ is more aggressive in adding social networking features. Being ultra-conservative just to "avoid breaking things" will mean the business can go bankrupt and thus, there's no website to even worry about breaking. [1] excerpt from: https://theweek.com/articles/462863/stories-behind-3-great-business-mantras https://theweek.com/articles/462863/stories-behind-3-great-b...
0xff00ffee 7y ago
Put another way: MFaBT is a great strategy for design prototyping, not engineering. In engineering, you have 18-24 months to get a product out the door: there are no prototypes. In design thinking, the timelines are different, and you expect the first 20 versions not to work.
pjc50 7y ago
Subtly but importantly: it's only OK to break your own things. People hate it coming from Facebook because they hold the world's most powerful trove of personal information, and a reccommendation engine that gets to nudge what a lot of people think is important. Similarly self-driving cars.
- scarejunba 7y ago
  That's your personal restriction on MFABT but Facebook MFABT is most definitely "bias towards speed". It has no "don't break other people's things" in it. And they behave like that. Correctly, in my opinion. Even if I've been at the receiving end having to implement against their Marketing API (which once released a 2-week deprecation notice).
  - pjc50 7y ago
    Going around breaking other people's things is vandalism. The logic of smashed up bus shelters and tagged trains. It doesn't deserve respect, and if they do it too often they can expect a legal or regulatory challenge eventually. But the current crisis has undoubtedly put that back a couple of years.
    - scarejunba 7y ago
      You're not going to be able to mount a successful challenge against Facebook changing their APIs without sufficient warning.
throwaway894345 7y ago
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 critical systems and to a lesser extent for systems that can't get realtime updates, but if your app is non-critical (especially entertainment apps a la social media) and you can roll out a fix in a couple of hours, moving fast and breaking things is perfectly fine, especially for features which don't constitute core functionality. In the saas world, bugs are typically very cheap (or can be made very cheap via continuous deployment, microservice architectures, etc) and opportunity costs are through the roof. In that sense, moving fast and breaking things is probably eminently desirable, since it's cheaper to react to a bug than to delay an opportunity because you want to do quality assurance as though your software updates need to be mailed to users on physical media.
- mrkeen 7y ago
  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.
  - throwaway894345 7y ago
    It's important to note that there is a difference between "making crap" and "spending inordinate effort to preclude bugs from my software". The idea is that you write the best code you can as quickly as you reasonably can and provide the degree of quality that suits your economic situation. You will make mistakes, learn from them, and then the next iteration will be fast and incrementally better. In theory if not in practice, this will make you a better developer (better code and fewer bugs) more quickly than if you were to spend lots of time perfecting each project, never mind the value that is generated from the additional features that you've shipped (which you otherwise wouldn't have shipped if you were spending time scrutinizing your code for bugs).
yjftsjthsd-h 7y ago
> All of them are trying to be provocative in the same way: expect repeated failures when experimenting/exploring what success looks like. Sure, but the difference is scope of impact. If you want to learn to ride a bike, ski, write a book, be good at sports, whatever, then you're going to make a lot of mistakes in practice, where they won't matter, where they won't be published, and where they won't affect users. In MFABT, production isn't sacred, and that's the problem.
mrkeen 7y ago
> 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.
Zelphyr 7y ago
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."
- phendrenad2 7y ago
  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.

by jasode 7y ago

sremani 7y ago

I think it comes down to volume and rate of corrections. You will inevitably make mistakes in many endeavors and most mistakes are not fatal, but while making mistakes the rate of correction during this time puts you on the right path. Most of the criticism of "move fast and break things" is word thinking. The move fast part includes "rate of correction".

lnenad 7y ago
It's also the size of the corrections, doing daily builds probably means you've changed a small piece of functionality and even if stuff breaks it's usually a quick fix, whereas doing them monthly/bimonthly carries a much higher risk of completely breaking stuff and is much harder to fix.
braythwayt 7y ago
With respect... I would say that a great deal of the criticism I’ve seen is of behaviour that can be summarized as, “Move fast and break things for other people. But if we’re achieving our objectives, no need to correct.” It is not fair to characterize all “Move fast and break things” as falling into this egocentric bucket, but My anecdotal experience is that this is what attracts the most criticism.

rjkennedy98 7y ago

My favorite is by Samuel Beckett: > Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

lioeters 7y ago
"Fail better." That is so good, thanks for the quote!

lnenad 7y ago

Yeah, like many things in our sphere things are taken literally (I am guessing since it's always easy to criticize) and are taken like they're a global pattern every programmer in the world should follow (same goes with microservices, k8s etc...).

deleted 7y ago

[deleted]

wwweston 7y ago

I more or less like FB as an application (and I have no idea whether I should like Zuckerberg or not). But MFABT is different as a formulation: it articulates broken things an imperative rather than a side effect that needs to be persevered through. There's also context to it that matters -- everything from the great documentation diaspora from a decade back where they blew away a developer wiki that represented years of community effort to describe how to use the various APIs without having anything remotely like an adequate replacement, to changes a few months ago which temporarily had access to the "Friends Lists" features unavailable which made managing privacy settings more difficult. There's a lot of things FB does right too, but when looking at blunders, it's easy to have the catchy phrase come to mind and wonder if maaaybe someone overconfidently strode forward MFABT in mind when more caution might have been warranted. You can't make an omelete without breaking a few eggs, as they say, but if you say that often enough, you start to get some people who think cracking a few open means breakfast is ready.

jasode 7y ago
>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 message is actually "failures are the path to success". The rhetorical language is a form of reverse-pyschology. Another similar example is salespeople or romantic suitors trying to get "yes" instead of "no" from prospects. The "no" is undesirable but rejections are inevitable in the process. Thus, one reverse-psychology approach is to frame it as, "How many _rejections_ did you get today? Only 10? Go make some more phone calls until you get 50 more rejections!" It still doesn't mean rejections are the real goal. We're just humans playing with language to get past the fear of rejections holding us back.
- wwweston 7y ago
  > 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. Something like "Move fast, even if there's risks" or "Prefer momentum over risk aversion" would be the face-value formulation. > We're just humans playing with language And being played with by language. If language is powerful enough to orient someone on the benefits of preferring momentum over risk aversion, it's powerful enough to distract from the threshold where there's inadequate anticipation of consequences. Any given formulation may do one job better than another. MFABT is not an optimal expression. There are better ones.

apinstein 7y ago

There is an important distinction between MFABT and these other examples. In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. People make better decisions about the risks to take when they have to deal with the consequences. With MFABT the party doing the breaking isn’t often the one suffering from the breakage and that drastically changes the system dynamics of such a policy. It has a huge tragedy of the commons dynamic to it. I have seen so many companies and products end up getting stuck treading water due to these dynamics. It only even begins to be workable if you a) have almost no users so breaking is of little consequence or b) you have so much money coming in due to moving fast that you can pay for the cleanup. Always be aware of the primary and secondary effects of the system you implement.

jasode 7y ago
>In all of the other examples, the consequences of breaking accrue to the person making the decision to break things. If a fishing ship goes out to sea and fails to catch enough fish or is wrecked because of a storm, it affects the families of the crew and everyone else who depended on them. If Michael Jordan fails and misses the game-winning shot, it affects his whole team. If it's losing a playoff elimination game, it affects the workers at the sports arena because they don't the get the income from extra games. > With MFABT the party doing the breaking isn’t often the one suffering from the breakage I don't know about every company that's (misusing) MFABT but with Facebook, it was their mantra before 2012 when they were not making any profits and trying to survive while competing against the bigger website, Myspace. Their software engineers could have conceivably broken their website so badly that FB goes out of business. That's what happened with Knight Capital when they misconfigured a server and lost $450 million. MZ's aphorism is just a twist on a common observation about making progress. He expanded on it in an interview: >We've optimized so much of our culture around just making it so that people can come and build things quickly. Whether it's everything from having the right tools in the right development environment to build things quickly, to nightly code pushes, hiring the best people who have a bias toward just pushing things very quickly, very entrepreneurial. The whole culture is tuned around that. And I think there's probably something in that for other entrepreneurs to learn which is that making mistakes is okay. At the end of the day, the goal of building something is to build something, not to not make mistakes. [1] He actually does not want a broken Facebook system. But he also knows that if there are no mistakes, it means the team is not bold enough with adding features. Yes, they could die from a broken code deployment to production servers. But they'll also die if Myspace or Google+ is more aggressive in adding social networking features. Being ultra-conservative just to "avoid breaking things" will mean the business can go bankrupt and thus, there's no website to even worry about breaking. [1] excerpt from: https://theweek.com/articles/462863/stories-behind-3-great-business-mantras https://theweek.com/articles/462863/stories-behind-3-great-b...

0xff00ffee 7y ago

Put another way: MFaBT is a great strategy for design prototyping, not engineering. In engineering, you have 18-24 months to get a product out the door: there are no prototypes. In design thinking, the timelines are different, and you expect the first 20 versions not to work.

pjc50 7y ago

Subtly but importantly: it's only OK to break your own things. People hate it coming from Facebook because they hold the world's most powerful trove of personal information, and a reccommendation engine that gets to nudge what a lot of people think is important. Similarly self-driving cars.

scarejunba 7y ago
That's your personal restriction on MFABT but Facebook MFABT is most definitely "bias towards speed". It has no "don't break other people's things" in it. And they behave like that. Correctly, in my opinion. Even if I've been at the receiving end having to implement against their Marketing API (which once released a 2-week deprecation notice).
- pjc50 7y ago
  Going around breaking other people's things is vandalism. The logic of smashed up bus shelters and tagged trains. It doesn't deserve respect, and if they do it too often they can expect a legal or regulatory challenge eventually. But the current crisis has undoubtedly put that back a couple of years.
  - scarejunba 7y ago
    You're not going to be able to mount a successful challenge against Facebook changing their APIs without sufficient warning.

throwaway894345 7y ago

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 critical systems and to a lesser extent for systems that can't get realtime updates, but if your app is non-critical (especially entertainment apps a la social media) and you can roll out a fix in a couple of hours, moving fast and breaking things is perfectly fine, especially for features which don't constitute core functionality. In the saas world, bugs are typically very cheap (or can be made very cheap via continuous deployment, microservice architectures, etc) and opportunity costs are through the roof. In that sense, moving fast and breaking things is probably eminently desirable, since it's cheaper to react to a bug than to delay an opportunity because you want to do quality assurance as though your software updates need to be mailed to users on physical media.

mrkeen 7y ago
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.
- throwaway894345 7y ago
  It's important to note that there is a difference between "making crap" and "spending inordinate effort to preclude bugs from my software". The idea is that you write the best code you can as quickly as you reasonably can and provide the degree of quality that suits your economic situation. You will make mistakes, learn from them, and then the next iteration will be fast and incrementally better. In theory if not in practice, this will make you a better developer (better code and fewer bugs) more quickly than if you were to spend lots of time perfecting each project, never mind the value that is generated from the additional features that you've shipped (which you otherwise wouldn't have shipped if you were spending time scrutinizing your code for bugs).

yjftsjthsd-h 7y ago

> All of them are trying to be provocative in the same way: expect repeated failures when experimenting/exploring what success looks like. Sure, but the difference is scope of impact. If you want to learn to ride a bike, ski, write a book, be good at sports, whatever, then you're going to make a lot of mistakes in practice, where they won't matter, where they won't be published, and where they won't affect users. In MFABT, production isn't sacred, and that's the problem.

mrkeen 7y ago

> 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.

Zelphyr 7y ago

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."

phendrenad2 7y ago
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.