The reason why I do not like Facebook's strategy "Move Fast; Break Things" is two-fold:
Theory
In theory, it is not desirable to move fast and break things in certain areas of development and engineering.
This became painfully evident when Facebook suffered:
Data privacy breach by many who used its APIs as intended to harvest personal information of users without their consent (popularized by Cambridge Analytica).
Data breach of 50+ million users just last week.
Facebook -- and other "too big to fail" corporations, like Equifax -- may be able to get away with gross negligence, but vast majority of companies ranging in size from small start-ups to medium-sized companies may not be so lucky when they're slammed with class action and EU lawsuits for failing to properly secure and protect users' data.
You should not move fast and break things when it comes to data privacy and security controls on your platform. You should always carefully design and architect your platform with privacy and security in mind.
Practice
In practice, I have worked on many teams and for many employers who thought they were following Facebook's strategy "Move Fast; Break Things" when, in reality, they were using it as an excuse to push development teams to rapidly deliver features without allowing paying down technical debt or, at least, re-engineering a more proper, sustainable solution than the hack that was cobble up to meet unreasonable deadlines.
One manager, in particular, used "Move Fast; Break Things" to justify not writing unit tests. I recall them saying:
Unit tests will just slow us down. We need to be more agile.
Where We Disagree
I agree with some points you made.
For instance, I agree with the following statements:
In other words, you don't over-plan or procrastinate because it won't help.
Things will break. You won't get it correct the first time, Hell you won't get it correct even the second time.
The only thing required here is persistence, really.
But, this is where we disagree:
Rather than sitting and thinking about how to write some code correctly, you just write the code in the way you know ("move fast") and if you ever come into a problem while following that method ("break things"), you will realize what is the more correct way to write it.
Often times, writing code without giving the problem domain some thought may, at best, get you stuck in a corner that is very expensive to get out of, or may, at worst, have disastrous consequences in certain fields (e.g. medical, autonomous vehicles).
You have to give the problem, your approach/solution, and any assumptions you're making along the way some thought before you start writing code.
The reason why I do not like Facebook's strategy "Move Fast; Break Things" is two-fold:
Theory
In theory, it is not desirable to move fast and break things in certain areas of development and engineering.
This became painfully evident when Facebook suffered:
Facebook -- and other "too big to fail" corporations, like Equifax -- may be able to get away with gross negligence, but vast majority of companies ranging in size from small start-ups to medium-sized companies may not be so lucky when they're slammed with class action and EU lawsuits for failing to properly secure and protect users' data.
You should not move fast and break things when it comes to data privacy and security controls on your platform. You should always carefully design and architect your platform with privacy and security in mind.
Practice
In practice, I have worked on many teams and for many employers who thought they were following Facebook's strategy "Move Fast; Break Things" when, in reality, they were using it as an excuse to push development teams to rapidly deliver features without allowing paying down technical debt or, at least, re-engineering a more proper, sustainable solution than the hack that was cobble up to meet unreasonable deadlines.
One manager, in particular, used "Move Fast; Break Things" to justify not writing unit tests. I recall them saying:
Where We Disagree
I agree with some points you made.
For instance, I agree with the following statements:
But, this is where we disagree:
Often times, writing code without giving the problem domain some thought may, at best, get you stuck in a corner that is very expensive to get out of, or may, at worst, have disastrous consequences in certain fields (e.g. medical, autonomous vehicles).
You have to give the problem, your approach/solution, and any assumptions you're making along the way some thought before you start writing code.
Your points are valid. I didn't think about it in that context, nor did I meant it to be.