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 Uberlearned it the hard way.