31–40 of 99 posts
"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.
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.).
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…
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 ri…
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 h…
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.
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 ri…
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.
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.
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?
Earlier quoted context omitted.
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.
`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 _lik…
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.
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 h…
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 year…
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.