Move Fast and Break Things is Not Dead
Move Fast, Fix Shit, and Learn Faster
If hard work is the key to success, most people would rather pick the lock. — Claude McDonald
“Moving fast and breaking things” is at the heart of the startup philosophy of being scrappy. Facebook was a notable proponent and adorned every one of its offices with the such posters — as a celebration of the hacker mindset and a reminder that the college kids were running the social show.
This “hacker” way of working usually emphasizes testing out new ideas, iterating quickly based on data, and aiming for more frequent points of learning. It focuses on velocity with little regard for quality. Many companies misunderstand “move fast and break things” to mean that making a mess is the same as innovating. They fail to grasp that you have to move fast and break the right things for this to work.
When an OkCupid software engineer pushed a small change, the company’s servers went up in flames. And he thinks that’s okay:
For most businesses, however, a software crash is not a death knell. If you’re not building self-driving cars, storing sensitive information, or supporting the data backbone of the internet, it may not matter if an error interrupts your service. It’s okay, for example, if a free online dating site goes down for an hour or half a day. In fact, it might even be better for business to trade off bugginess for forward momentum — the ethos behind Facebook’s old mantra “move fast and break things.”
When you allow yourself to build imperfect systems, you start to work differently — faster, more ambitiously. You know that sometimes your system will go down and you’ll have to repair it, but that’s okay. “The fact that it’s easy to fix things means you end up with this methodology where you think, ‘Let’s get a broken thing out there as fast as possible that does sort of what we want, and then we’ll just fix it up,’” says David. That’s not necessarily a bad thing, since preventing errors is inherently difficult. “Even if you spend a whole bunch of time trying to make something that’s perfect, you won’t necessarily succeed,” he explains.
OkCupid was a complex site. Had we tried to make it perfect, it might not have come to exist in the first place.
His then-CEO used to say, “We can’t sacrifice forward momentum for technical debt.” That is, just build it and don’t worry about the problems building up. It’s classic legacy and a clear example of decisions taken early on during the development and coding process coming back to bite you later.
If (the database throws an error) { do nothing }
The concept “technical debt” in software design and development comes from Agile development guru Ward Cunningham. He used it to describe what happens when you rush to ship software without applying what you’ve learned about the problem you’re trying to solve.
Technical debt happens every time you do things that might get you closer to your goal now but create problems that you’ll have to fix later. As you move fast and break things, you will certainly accumulate technical debt.
Since you build incremental parts of the codebase as quickly as possible, there is less capacity to think about how any given part will hold up and fit in the bigger picture over time. Shortcuts will be taken in the code, and code tests will not fully cover all the edge cases. Nobody is maliciously pushing bad code, but developers can easily fall into the mind trap that, since everything is “just a test”, it doesn’t make much sense to double the development time and effort to write code correctly and test thoroughly.
The interest payment on that debt is the extra effort that you must put into future development due to earlier design choices or defects. The longer you leave it unpaid, the higher those payments get. Eventually, it might slow you down to the point where you can’t ship new features or innovate, potentially costing your business a ton of money or customers — and your developers their hair.
You have to avoid debt because debt makes the system more fragile. You have to increase redundancies in some spaces. — Nassim Nicholas Taleb
Like any debt, technical debt must be paid down. What happens when you don’t? You inevitably reach the point where all the accumulated debt makes the entire system so complicated and so expensive to maintain that it falls out of date and eventually out of step with your business. It can slow you down at precisely the point that you’re supposed to be powering ahead. The layers and layers of bandages put on top of each other over time might fall off all at once, revealing every open wound. You can wait until then to try to fix things, like the people who sold collateralized debt obligations (CDOs) and credit default swaps (CDSs).
… software is built on top of other software. You’re working not just with your own code but with code from your coworkers and from third-party software libraries. If these dependencies are buggy or complicated or behave in non-intuitive ways, errors may seep into the software that relies on them.
Merely measuring the number of defects per thousand lines of code isn’t enough — you have to look at the severity of the bugs, too. Measuring technical debt may make it easier to manage, or at least give you a starting point to determine which defects matter the most to accomplishing your goals for the product and the company. Then, paying down that debt by targeting it becomes a budgetary decision.
This Silicon Valley-homegrown attitude of “moving fast and breaking things” has not only become standard startup advice, but also has even evolved into an international movement. Events, TED talks, festivals, best-selling books…you name it.
But as Facebook matured and started to get nearly 500 billion API calls a day to access its platform, Zuckerberg shifted the focus from speed to efficiency and dependability — and changed the motto to “move fast with stable infrastructure.”
Because when you build something that you don’t have to fix 10 times, you can move forward on top of what you’ve built. — Mark Zuckerberg
Along with the abandonment of its early motto, Facebook announced a 2-year stability guarantee for its core products — such that it would no longer risk breaking other companies’ apps when updating its own plug-ins — alongside a promise to fix all major and minor bugs in 48 hours.
The startups that moved fast and broke things have been egged on by return-hungry venture capitalists and their companion motto, “growth at any cost.”
In order to become a company that transcends the mobile platform wars, Zuckerberg realized that you can’t move too fast and some things aren’t worth breaking. Theranos, Zenefits, and Uber learned it the hard way.
That, however, doesn’t mean “move fast and break things” is dead. The phrase still makes perfect sense in anti-fragile systems. A classic example of something anti-fragile is Hydra, the Greek mythological creature that has numerous heads. When one is cut off, two grow back in its place.
Nassim Nicholas Taleb writes in Antifragile: Things That Gain from Disorder:
Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure , risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better. This property is behind everything that has changed with time: evolution, culture, ideas, revolutions, political systems, technological innovation, cultural and economic success, corporate survival, good recipes (say, chicken soup or steak tartare with a drop of cognac), the rise of cities, cultures, legal systems, equatorial forests, bacterial resistance … even our own existence as a species on this planet. And antifragility determines the boundary between what is living and organic (or complex), say, the human body, and what is inert, say, a physical object like the stapler on your desk.
Such systems are not only resilient to your breaking things, but also actually improve when you break things. In effect, they “learn.” For example, when you are building a new product that a lot of people might want to try but no one’s life is depending on it, move fast and break things because you actually benefit from the volatility and unpredictable disruptions.
You don’t have to wait for your product to be perfect before releasing it into the market. Microsoft kicked Apple’s ass in the 1990s because they released products that weren’t quite ready and fixed them as soon as they got feedback. Steve Jobs, on the contrary, waited for everything to be perfect before showing anyone.
Crucially, if antifragility is the property of all those natural (and complex) systems that have survived, depriving these systems of volatility, randomness, and stressors will harm them. They will weaken, die, or blow up. — Nassim Nicholas Taleb
But when you are building mission-critical products, such as a space shuttle that people will have to rely on to keep themselves alive, or products that absolutely must work every time or it could cost operators millions of dollars (Knight Capital is a good recent example of this), or when your business relies on a small number of big customers, you should move slowly and steadily and test the crap out of every change before releasing. Broken products scare people off, which in turn damages your reputation and tanks your business.
In product development, the downside risk tends to be much higher than the upside and the probability of getting any sort of return on investment is relatively small. There are lots of risks, different paths to take, many degrees of freedom and innumerous ways it can go wrong. Wrapping things up rapidly into a delivery vehicle called “project” tends to negatively skew the asymmetry of the payoff function.
Innovation requires that we explore new grounds and break things, thinking the unthinkable and discovering the best solution. Probe, sense, respond: Amplify the positive signal, and decrease the negative signal. Projects hide a lot of these small incremental and iterative bets, and provide management with a false sense of control and visibility.
In the context of product development, the improvement opportunity lies in generating valuable and actionable feedback from what doesn’t work. Counterintuitively, that information is often crucial. If there is no feedback loop in place paying attention to this mechanism, the learning opportunity is lost. Perhaps the motto should be updated to something like
Obviously it doesn’t sound as catchy as Facebook’s mantra. But don’t be fooled into thinking that breaking stuff is inherently good. It’s not. And it apparently doesn’t apply in all contexts, as the XKCD comic illustrates.
Thanks for reading!
If you enjoyed this post, feel free to give it many claps 👏 (you know you want to!) or share with a friend. Follow me for more stories.