“Move fast and break stuff” is a decent philosophy if and only if the consequences of breaking stuff are survivable.

• If breaking stuff means that your website looks weird, that’s survivable.

• If breaking stuff means that performance sucks for a while, that’s survivable.

• If breaking stuff causes unavailability during a critical period of end-user demand, a few incidents might be survivable.

• If breaking stuff causes your company to have a terrible reputation for privacy, security, or competency, that might not be survivable.

• If breaking stuff causes your company to divulge financial information, that might not be survivable.

• If breaking stuff ends up costing your customers any significant amount of money, that probably will not be survivable.

The problem is that the philosophy you set for routine activities will tend to carry over by default. Oh, and it turns out that UI problems sometimes become major flaws, so even changes that you thought were perfectly safe can be problematic.

Testing, QA, security and release engineering are not your enemies. They are features of healthy organizations.

“move fast and break things” is, at its best, a recognition that innovating is a high-risk activity. Failure of one scheme doesn’t mean you should stop trying, but it could be a sign that you need to move slowly and get it right.