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

71–80 of 99 posts

Re: The Fallacy of Move Fast and Break Things

#71

Post by throwaway894345 »

mrkeen wrote: post #62
throwaway894345 wrote: post #53

Earlier quoted context omitted.

I always interpreted it as a recognition of different economic models between what we're taught in school ("software bugs will kill people! Remember the Therac-25! Remember the Patriot missile failure! Even if your bugs don't kill people, bugs found late in the lifecycle are super expensive (based on a single paper from 1990 or something)") and that of most saas applications. The academic attitude is appropriate for…

I've tried to treat my unimportant app developer career as being a stepping stone to something more important. Even if it's OK to release crap today, where will I be in 10 years time if that's what I have been practicing? I'd rather try to release bug-free software now, even if it causes friction where I work.

It's important to note that there is a difference between "making crap" and "spending inordinate effort to preclude bugs from my software". The idea is that you write the best code you can as quickly as you reasonably can and provide the degree of quality that suits your economic situation. You will make mistakes, learn from them, and then the next iteration will be fast and incrementally better. In theory if not in practice, this will make you a better developer (better code and fewer bugs) more quickly than if you were to spend lots of time perfecting each project, never mind the value that is generated from the additional features that you've shipped (which you otherwise wouldn't have shipped if you were spending time scrutinizing your code for bugs).

Re: The Fallacy of Move Fast and Break Things

#72

Post by myhf »

jasode wrote: post #40
wwweston wrote: post #36

Earlier quoted context omitted.

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…

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

Facebook's business model is to "move fast" (to outmaneuvre the competition) and "break things" (to disrupt the incumbents). It's clearly intended as a desirable imperative.

Re: The Fallacy of Move Fast and Break Things

#73

Post by tmcb »

Finnucane wrote: post #68
tmcb wrote: post #47

Earlier quoted context omitted.

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.

Right, because who cares if it's broken crap as long as it's generating revenue.

This sarcastic remark is entirely misguided. Broken crap does not generate revenue; working code does. But, oftentimes, no code is as effective as broken code, and takes longer to fix. This is when you should use your judgment. “Break things” is not the same as committing faulty code, it just means that validating some of your hypotheses in a controlled environment may have a higher cost.

Just to make things clearer, I am a programmer myself, and have never been in a management position before. My overall impression is that I learn faster when I make mistakes and need to fix them. Expecting otherwise would contradict most of the experts on human learning.

Re: The Fallacy of Move Fast and Break Things

#74

Post by zepto »

roosterdawn wrote: post #52
zepto wrote: post #39

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

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

Re: The Fallacy of Move Fast and Break Things

#75

Post by zepto »

LgWoodenBadger wrote: post #45
zepto wrote: post #39

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…

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?

I’d rather people not think that the risk is lowered because of the code size.

It’s a red herring. Risk is lowered because the code is understood better not because the code is smaller.

The assumption that each change carries an equal risk of disaster isn’t valid, because risk depends on your understanding of the changes and the codebase.

Risk is equal only in the case where the developers know nothing about the change or the codebase. In this case, fire the VP of engineering or equivalent.

Making changes as a series of small increments can just as easily lead to less understanding of the overall impact of the changes than a larger design process. Then you get a nice big failure from a small change. It looks like most of the changes were harmless when in fact they were all just building towards the one that caused the failure.

Re: The Fallacy of Move Fast and Break Things

#76

Post by tmcb »

mdorazio wrote: post #60
tmcb wrote: post #47

Earlier quoted context omitted.

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.

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.

Re: The Fallacy of Move Fast and Break Things

#78

Post by collyw »

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?

I agree with you on this but just as a counter point about Doctors. Someone on here a few months back speculated that the reason a lot of the top doctors in the US were from India is because they basically got the chance to "break a few things" back home before they got to the States. As such they got valuable learning experience that would not be possible with the stricter regulations in the US.

Re: The Fallacy of Move Fast and Break Things

#79

Post by hinkley »

codingdave wrote: post #5

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.

Well, I mean "It's better to burn out than to fade away" is a motto too, but it's one that people backpedal on when their organs start to suffer the consequences of their hard-living.

Re: The Fallacy of Move Fast and Break Things

#80

Post by collyw »

sixstringtheory wrote: post #64
mark-r wrote: post #49

Earlier quoted context omitted.

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

And the version most pertinent to us developers: "Weeks of coding can save you hours of planning."

I wish more developers would follow this advice. I think I am the only person I know that draws diagrams with pen and paper before typing out code to clarify my though process. Occasionally we get some whiteboard high level stuff with some boxes and lots of arrows but that's about it.
Post reply on HN