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 it everyday while there are others that absolutely loathe it.
I, for one, used to be not much of a strong believer in this. But then, through my own life experiences, I realized how this works.
There are two components to it -
(1) Move Fast
The first idea is pretty simple. You move fast. You do things fast. You work fast. In other words, you don't over-plan or procrastinate because it won't help.
(2) Break Things
Things will break. You won't get it correct the first time, Hell you won't get it correct even the second time. Why? Because it is hard to make correct assumptions. There are things that you cannot just assume. I have learned this myself, the hard way.
Instead, you should mold your product as you keep running into roadblocks. With enough perseverance on your part, you will eventually make it out, and be a success.
This applies to non-startup things like learning a programming language too.
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.
Repeat this cycle many times and you are eventually a pro.
I don't know of any other way that is more guaranteed to return results like this one. The only thing required here is persistence, really. If you think you have it, this approach is for you.
Otherwise, you go slowly.
Moving fast, breaking things, and then quitting when things break won't work.
PS - Want to learn more? Get yourself a copy of Rework and read it in one sitting (just kidding, I did it though). It will surely change some of your views on entrepreneurship and by extension, life.
Top comments (3)
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