First posted on Dev Letters
Move Fast and Break Things - such a popular saying in the startup world. Some are so in favor of it that they sing...
For further actions, you may consider blocking this person and/or reporting abuse
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.
I'm currently a data-science student and have been practicing this methodology for my life until I realised that all I was doing was: doing too fast, pattern matching, hacking my way to solutions, missing tons of important elements. What I learnt is that not taking the time to do things correctly adds up until you're totally lost, it be in your code, in your studies or in your work. I get the principles and see how this kind of stimulations allowed me to think fast for all these years, but I also totally see how it traduce in the industry in bad coding practice/documentation, not well thought code etc. I would say you can apply this principles in R&D but other field have probably more to gain with TDD overall, unless you're keen to repeating mistakes over and over