
The Fallacy of Move Fast and Break Things - kiyanwang
https://launchdarkly.com/blog/the-fallacy-of-move-fast-and-break-things/
======
jasode
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)

~~~
wwweston
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
_> 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
> 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.

~~~
jasode
_> "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.

[1]
[https://www.lexico.com/en/definition/imperative](https://www.lexico.com/en/definition/imperative)

------
PaulRobinson
Lot of answers so far seem to have missed the points being made in the book
the article references.

If you have the ability to ship things fast - and so do regularly - you will
find that your releases:

\- Have a small blast radius if there are bugs, because how much blast can you
have in an hour's work versus a quarter's?

\- The tooling that you build to let you go fast will tell you that a blast is
indeed happening right now

\- Your Mean-Time-To-Resolution (MTTR) is lower because you can just roll it
back. It's not days or weeks of work to get a rollback out, it's minutes.

\- That having a culture of being able to release continuously and quickly
allows you to go fast, and the occasional breakage is tolerable, because the
cost is low.

You can go slow if you want. And if you don't have LEST metrics or have slow
release processes you _must_ , but if you work to get to the point where you
are able to move fast, you'll find that you break things less and fix them
quicker when they do break.

The alternative is you still break things, but the problems incurred are much,
much greater.

Also note: there are some environments where continuous deployment is never
going to be an option or desirable. Thankfully these environments tend to be
ones where the market will tolerate the higher costs of formal methods and a
more deliberative quality control process (medical devices, aerospace, nuclear
reactors, etc.).

~~~
altcognito
I like everything except the small blast radius point here. You can do a lot
of damage in a short period of time with computers.

~~~
PaulRobinson
`sudo rm -rf /` is a very big thing to do in a very small amount of code,
sure. I'd adovocate thinking about probabilities then:

If you have a shorter period of time to produce a smaller change, are you more
or less likely to have a smaller blast radius than if you have a longer period
of time to produce a much larger change?

There are no absolutes, but we're talking about risk here, and risk is about
impact and _likelihood_. Your impacts are going to be smaller and your
likelihood of big blast radiuses are _less likely_, but not ruled out.

~~~
zepto
I’d say that change duration is irrelevant to blast radius, because bug impact
is independent of code size.

Having said that - a smaller piece of code is easier to understand, so there
is more potential to notice problems.

However that depends on whether you do that diligence. And the dangerously
false belief that the blast radius is going to be smaller because of change
size rather than understanding works against you.

~~~
roosterdawn
I don't know whether a smaller change means necessarily a lower probability of
small blast radius, but the larger a code change is the higher the probability
is of a high blast radius. Blast radius isn't necessarily going to be smaller
because of change size, but the chance of it being smaller certainly does
decrease in relative terms as it becomes smaller even if it never reaches zero
and is still in absolute terms quite high. It's still a noticeable improvement
and because of that still a worthy goal to pursue, nevermind the ancillary
improvements to product/design/engineering/business coordination and delivery
volume as a result of lower iteration cycle time. That's the larger win for
me.

~~~
zepto
The chance per change size may be reduced, but you are are going to more
changes, so the overall probability is unaffected.

------
Finnucane
"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?

~~~
mrlala
>"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 you know what? I can fix that afterwards. It
doesn't matter that I broke something to get something else to work.

~~~
DoofusOfDeath
I think the carpenter analogy is actually very good: it gives us a starting
point for thinking about where MFABT is / isn't a good idea.

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

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

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

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

~~~
bigpeet
Pretty much spot-on.

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

~~~
gentleman11
Do you have a link to that by chance?

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

~~~
dasil003
I feel this reasoning easily slips into no-true-Scotsman territory. Did FB
have product-market fit in 2006? 2008? 2013? They didn’t just move fast during
prototyping, this went on for years and years of hypergrowth. There was
customer backlash at each major release as they overhauled the product but it
turns out they knew better than the customers themselves knew what they
wanted.

Friendster and MySpace by contrast slowed way down once they hit traction, but
it didn’t enable them to solve their scalability issues.

~~~
jcelerier
> it turns out they knew better than the customers themselves knew what they
> wanted.

do we live in the same universe ? facebook has already one full step in the
big storage room with myspace, omegle, etc. most teens I know laugh at you if
you say you're using facebook like you're some decrepit old person.

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

~~~
hef19898
Also, make sure you are running in the right direction. Ideally before moving
fast.

------
vbtemp
I might not have a multi-billion dollar company, but Think deliberately, Code
carefully, Test thoroughly seems to maximize success for minimal stress...

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

------
tabtab
It's a matter of knowing your audience and knowing your funder's/owner's goals
and expected risk-reward trade-off profile.

A "cowboy" mentality may indeed help a start-up edge out competitors. But
applying that to an established company can ruin your reputation: you have
more to lose by playing fast and loose. Startups by nature are a gamble, but
if an established corporation gambles too often they may poke a hole in their
dam that they can't patch fast enough.

Venture capitalists usually factor in a high failure rate to startups they
invest in. Their plan is that enough will succeed in a big way to counter the
high failure rate.

A lot of "fads gone wrong" happen when a technique or technology that works
for one situation or size is misapplied to another. Your office printer
inventory tracker doesn't need microservices and web-scale databases.

Pilot projects with new technology is often a good thing, but don't bet key
organizational functions on such a project (sometimes called line-of-business
systems).

------
dahart
> The 2019 report showed elite companies have 46 times more frequent code
> deployments than low-performing teams and a 2,555 times faster lead time to
> move from code commit to deploy to support their initiatives to move faster.

> Yes, elite teams ship faster. But, their changes are 1/7 as likely to fail,
> and they recover from incidents 2,604 times faster than low-performing
> teams.

Since the report is behind a form, and the form is having trouble loading for
me right now, I’ll just ask if anyone knows the context behind these numbers?

These numbers seem very large for any kind of average; are they choosing the
most extreme cases? I feel like they also only make sense in units of seconds
or minutes, otherwise we’re comparing hours to weeks or days to years.

------
vanderZwan
I think it was someone on HN who said _" I wish we focused more on moving slow
and fixing things"_ and I still think of that remark whenever something breaks
or isn't quite working as intended on my computer or phone.

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

------
comprev
Original article: [https://devops.com/the-fallacy-of-move-fast-and-break-
things...](https://devops.com/the-fallacy-of-move-fast-and-break-things/)

------
ragebol
I've always thought that you can only apply this mantra when you can _afford_
to break things. Which you can only do when the thing you break is not
critical to anything.

------
gentleman11
I am reading Bob Martins Clean Architecture right now. The introduction takes
the opposite stance: that there is no such thing as moving fast in a sloppy
way, because even in the short term quality code yields faster development
times.

This is meant to include changeability: quality code should theoretically
yield faster iterations too. This “break things” aspect is something I believe
he opposes.

Is he right? Wrong?

------
downerending
Reminds me of a quote I cannot locate, but will paraphrase: _Any career, no
matter how successful, will ultimately feel like a series of failures._ That's
not meant as a downer, but rather just that it's often hard to tell.

As to MFABT, the proper adjustment of that knob in a particular situation is
difficult and is what expertise is all about.

------
dang
[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=%22move%20slowly%22%20%22preserve%20things%22&sort=byDate&type=comment)

------
fleddr
From the article:

"As consumers and end-users of software, our expectations are continually
rising."

A very agreeable statement, but no they're not. Expectations are that your
service works, makes sense, is easy to use. This is not a rise in
expectations, it has always been there.

------
tmcb

      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.

------
Koshkin
There are some things I wouldn't want to break, ever. _Think_ before you move.

------
zackmorris
The basic assumptions behind move fast and break things:

* We don’t know what the final solution will look like, because of things like scope creep and client demands.

* The more agile the team is, the higher the velocity and ability to iterate.

* The more specialized roles we have (like project manager, team lead and junior developer) the more we can focus on completing tickets to increase velocity.

Which I counter with:

* We actually do know what the final solution will look like. I normally have an idea of what clients are asking for before they finish their sentences. Then I extrapolate to the fundamental problems and meta concepts around their specific problem. I’ve already formulated solutions and am solving them in my mind, until I isolate the unknown steps (the hard steps), whose odds of me being able to solve them are the basis of my estimate. Most of my work today goes into research, setup, glue code, infrastructure and maintenance. Solving the client’s actual problem constitutes perhaps 5% of the work I must do.

* We can always iterate faster in our minds than in the real world. With a proper architecture budget, we can take time in the beginning to brainstorm the complete solution before we ever start writing code. Then if we follow proper quality assurance practices like test-driven development, we can write code that is free of technical debt and bugs. All the while exerting substantially less effort than writing the same thing several times.

* Agile programming wasn’t really a thing until the rise of large internet companies and the marginalization of individual software developers. It’s curious to me that the people with the most say in writing solutions have the least clout in organizations. I feel that this is due to supply-side economics and wealth inequality. So today we cater to client first, then organization, then software developer. That’s what the specialization in agile is really all about. But we should be doing something more like movie production, so the client is the producer, the organization is the director (or movie studio) and developers are the actors. The industry should have more confidence in the process and have conventions which mitigate the churn caused by clients’ fickleness and low understanding of the problem domain. But right now it feels like the emphasis is on getting every scene filmed as fast as possible. We pretend that developers have no gravitas and are just interchangeable cogs in the machine. It’s no surprise to me that most productions bomb in the box office.

To use construction as an analogy: programmers used to be akin to architects,
spending time in the beginning to draft a plan that includes all contingencies
so that the building doesn’t fall down (a right-brained or politically-blue
approach based on creativity, insight, seeing outside the box, etc). Today
we’re being told to be framers, hammering out solutions as fast as we can over
and over again in order to get things done until the building is finished (a
left-brained or politically-red approach based on a strong work ethic,
discipline, loyalty, not getting distracted, etc).

I think these are both important, and over the last year I have been working
on my “getting things done” side to improve my execution ability. But I will
always be a dreamer and value the intuitive side of software development. The
idea that we can manifest solutions in the real world with the power of our
minds is what got me into programming in the first place. The trend towards
application and turning programming into just another job has soured me on the
field in general. I’m actually not entirely certain that I can do it anymore.
So to me, the true cost of move fast and break things is the loss of people
like me who thought that this was all going to go a different direction.

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

