91–99 of 99 posts
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?
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 change…
Earlier quoted context omitted.
There's a rather big difference between breaking things in a test & learning environment (all of the examples you provided) and breaking things in a production release.
There is also a big difference between a profession that respects the intelligence of their peers and one where people assume that their peers are ignorant and lack common sense. Surgeons must act fast and be good at multitasking. I bet they are not in a forum discussing if those traits make them vulnerable to hasty decisions and to loss of concentration on the task at hand.
Earlier quoted context omitted.
There is also a big difference between a profession that respects the intelligence of their peers and one where people assume that their peers are ignorant and lack common sense. Surgeons must act fast and be good at multitasking. I bet they are not in a forum discussing if those traits make them vulnerable to hasty decisions and to loss of concentration on the task at hand.
I'm genuinely not sure what your point is. Can you explain it? The two surgeons I know generally have extreme trust that their tools, monitors, etc. will "just work" when and where they are needed, every time, and that those things have been properly vetted by the medical industry and community prior to going into a live hospital environment unless it's specifically known that they are testing something new.
Competent developers, on the other hand, have extreme trust on the judgment of their peers. They know they won't break the production build at will; if they ever do, they will use all information gathered to improve the team's infrastructure and their own development process. They are not afraid of using the term, because breaking things is the most valuable thing that you can do for your learning, but, most importantly, they realize that other people's lives and goods are potentially at stake, and act with due diligence.
So, "break things" is not an excuse to break the production build at will and move on to the next task. If competent developers ever find themselves in a team that does so, they try to educate the team and, if that does not work, GTFO.
Earlier quoted context omitted.
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.
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).
Earlier quoted context omitted.
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 y…
I think blast radius is basically bug size * mean time to recovery Further I believe bug size is usually proportionate to change size, and MTTR is a function of how long it takes to get a change out into user’s hands So if you release early, release often and keep an eye on your metrics, you stand a good chance of your blast radius being consistently low. You won’t eliminate it, you’ll just be beating the team with r…
What is the underlying mechanism that makes it so?
Earlier quoted context omitted.
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).
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.
"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…