Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fallacy of Move Fast and Break Things

launchdarkly.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: The Fallacy of Move Fast and Break Things

#41

Post by apinstein »

jasode wrote: post #14

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

Re: The Fallacy of Move Fast and Break Things

#42

Post by toddh »

altcognito wrote: post #35
PaulRobinson wrote: post #32

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.

Programs can be very efficient disaster compression algorithms.

Re: The Fallacy of Move Fast and Break Things

#43

Post by jasoncabot »

PaulRobinson wrote: post #32

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…

What are LEST metrics? I couldn't seem to find anything from Google and now it feels like I'm missing some major concept

Re: The Fallacy of Move Fast and Break Things

#44

Post by lioeters »

rjkennedy98 wrote: post #21
jasode wrote: post #14

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…

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

"Fail better." That is so good, thanks for the quote!

Re: The Fallacy of Move Fast and Break Things

#45

Post by LgWoodenBadger »

zepto wrote: post #39
PaulRobinson wrote: post #37

Earlier quoted context omitted.

`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…

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…

If you assume that any and every change could have a disastrous effect, would you rather have to deal with one change at a time or many changes at a time?

Re: The Fallacy of Move Fast and Break Things

#46

Post by 0xff00ffee »

jasode wrote: post #14

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…

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.

Re: The Fallacy of Move Fast and Break Things

#47

Post by tmcb »

Finnucane wrote: post #38

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

Thing is, they do, but not in the ways you would expect. Cadavers on medical schools. Wind tunnel modeling. Computer-aided designs. The main difference to those is that the software industry can indulge on testing its own assets with little to no cost, and especially if that does not impact your ability to generate revenue.

Re: The Fallacy of Move Fast and Break Things

#48

Post by mrlala »

Finnucane wrote: post #38

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

Re: The Fallacy of Move Fast and Break Things

#49

Post by mark-r »

Finnucane wrote: post #38

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

"Measure twice, cut once" I think is the saying carpenters use.

Re: The Fallacy of Move Fast and Break Things

#50

Post by pjc50 »

jasode wrote: post #14

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…

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.
Post reply on HN