Comment by jseliger | Hacker News Reader

Comment by jseliger | Hacker News Reader

“Move fast and break things,” they said. It turns out that’s a pretty bad idea when your business relies on a small number of large customers. Broken products tend to scare them off, which in turn tanks your business. There’s a lot to be said for building things that work, but “move slowly and steadily towards a goal” just doesn’t have the same ring.

In reality, there’s a balance between moving fast and and moving slow. It’s difficult to communicate that balance because every type of product demands a different balance. I suppose that intuition comes from experience, which is a terrible answer for someone trying to learn.

I'm guessing this continuum also depends on the nature of the business one is in. In a fast-moving, consumer-oriented world like social networking, "move fast and break things" is probably very good advice.

In a slower-moving, enterprise-oriented world, "move slowly and steadily without breaking things" is probably the right orientation. Those kinds of companies probably die in fast-moving consumer land.

A while ago I read an article about the programming teams that work on the space station, on satellites, and that sort of thing. Alas, I cannot find the link right now, but the gist was that those teams move very slowly and work very hard towards correctness. Any bug found is generalized and their entire code base scoured for similar bugs. That's a different environment than social networking.

Most enterprise customers I've dealt with don't even care about things breaking that much, they care about control. That's the much bigger thing. Things break. Let's just make sure we don't break things while our customer is dumping silly amounts of money into an EU-wide advertisement campaign. Or we tend to freeze updates during christmas, due to the christmas business of our customers.

With those guys, it's fine to execute risky changes on productive systems, as long as those changes are tested, communicated, scheduled to a non-critical time of the customers and include backoff-plans.

But yes, this naturally slows things down, or makes systems more complex and expensive due to redundancy and staged rollouts.

Enterprise wise, they are very forgiving in my experience unless it affects their customer. Then they are very unhappy, understandably so.

It really comes down to risk management. Engineering is the discipline of making trade-offs, one of which is deciding when a risk is acceptable.

If the risk to your end users is low, or the hazards are minimal, then yeah you can push crap code to production daily because nobody is actually harmed by it. If the crap code carries a risk of say bringing down your payment or accounts system, causing you to lose revenue, then you might spend more time mitigating the risk by testing, reviewing, and improving the code.

On the extreme end of the spectrum, where the hazards posed by bugs crash your spacecraft into the atmosphere or break your $300 million dollar probe, you tend to spend a lot of time validating and verifying your solution because a single mistake is very costly.

cannot find the link right now, but the gist was that those teams move very slowly and work very hard towards correctness.

https://www.fastcompany.com/28121/they-write-right-stuff

Re: "Move fast and break things" - That strategy may indeed work for startups who depend on "bulk" customers. If you muck up say 5% of their accounts by taking high risks, you still have 95%. Growth is more valuable than retention at that stage. However, if a bank fouled up 5% of their customer accounts, they'd get sued to oblivion and/or make the front page. Know the domain, know the customer, one size does NOT fit all.

Somebody at our org converted everything to microservices because some fast-talkin' marketer got into their head. It's now a pasta mess. We didn't NEED microservices; wrong tool for the job.

> In a fast-moving, consumer-oriented world like social networking, "move fast and break things" is probably very good advice.

I'm not so sure about that particular example, given the privacy implications. (And beyond...)

If your mantra specifically encourages breaking things in production, you've chosen to be flippant instead of thoughtful; or you actually want your product to be broken. It's likely that a more thoughtful mantra could result in better outcomes without discouraging urgency and innovation.

Move fast and break things, I think, is good advice. Why on Earth you would ship said broken thing, I don't know. But the whole point of moving fast and breaking things is to see where things get broken, so you have time to fix it before you ship it.

Reply on news.ycombinator.com