Facebook is famous for having the motto "Move fast and break things" for the early part of its life. Then, in 2014 they changed it to "Move fast with stable infra." Googling for "Move fast and break things" today brings up a lot of articles around that change and questioning the original motto.

Whether or not the first motto is the correct business decision, it works better as a motto. It sets forth two ideas that might both be goals a priori, moving fast and not breaking things, then explicitly prioritizes one over the other. Even better, it has a built-in benchmark for exactly how much you should prioritize moving fast: move fast enough so that you're breaking things.

The 2014 motto is worse in that regard, in that it puts forth two ideals and says to prioritize both. As a result, it ends up saying almost nothing. If you were working on Facebook's infrastructure, how fast are you supposed to move? Presumably the idea is to have some sort of balance, but the motto doesn't give you any idea of how to figure out that balance either.

In addition, from my point of view, most of the pain of broken software doesn't happen when a change causes a break, but when the software breaks by itself without any changes happening. In the first case, usually the person who made the change is around to quickly make a fix or back it out, so the damage is usually limited to some embarrassment.

On the other hand, software breaking on its own has much more severe downsides. Depending on the timing, it may take much longer to get noticed and fixed. Furthermore, it could happen in the middle of the night, which means that somebody needs to have their sleep interrupted to fix the issue. When that happens a lot, being on call becomes tiring and a source of stress. Furthermore, unplanned incidents means that less time is spent moving the project forward, and is instead spent on just keeping the existing stuff running.

With that in mind, I'd like to see software projects adopt a motto that prioritizes software that doesn't break on its own. It should be fine to make a change that comes with risk of breakage, especially if that breakage will be noticed quickly and is able to be resolved or backed out. On the other hand, making a change with unknown effects on the long-term stability of the system should be considered much more dangerous.