For more than a decade now, a phrase coined by Mark Zuckerberg has helped shape not only the direction of his company, Meta, but the wider tech sector. “Move fast and break things” was one of the five values Zuckerberg believed embodied “the hacker way”, in a 2012 letter he wrote to be shared with potential investors into his company.

“Moving fast enables us to build more things and learn faster. However, as most companies grow, they slow down too much because they’re more afraid of making mistakes than they are of losing opportunities by moving too slowly,” he wrote. “We have a saying: “Move fast and break things.” The idea is that if you never break anything, you're probably not moving fast enough.”

With five words, Zuckerberg managed to encapsulate the tech sector’s drive to disrupt. Many founders will have emulated his approach, by allowing developers to break things as long as they are pushing the product and company forwards.

“Move fast and break things” has worked quite well for Meta, then Facebook. At the time the Meta CEO wrote the letter, his company was filing for a $5 billion initial public offering. Meta is now worth $1.5 trillion. And the share price has risen from around $38 then to $576 today.

But what are the limitations of a concept that has been so readily replicated and adopted across the sector?

The perils of breaking stuff

“Move fast” is almost always a cherished value for a company to have, and therefore it’s a vital quality for employees to have. But the “break things” can be a pejorative term that troubles as many as it comforts. Pushing new features in software as they’re being developed is admirable, but a move fast and break things mindset can also be perilous to a project.

“Hurrying to get a prototype out the door can lead to incomprehensible mistakes later down the line when the product aims to become more mature,” warned Zoe Lavoie, a software engineer, in a blog post back in 2021. She pointed to evidence of a project she worked on where the need to iterate at speed meant that long-term thinking was sacrificed for short-term success. We now know of this as technical debt.

When it comes to a discipline as carefully intertwined as software development, where decisions you make early on in a project can multiply and snowball over time, there’s a strong case for a more considered approach to development.

An argument against

Warnings about moving fast and breaking things are common across the sector. “More often than not moving fast and breaking things will result in shipping scrappy software. This is because in the rush to get stuff out the fastest way time-consuming things get skipped,” wrote Gergely Orosz back in 2016.

Skipping those core parts of the development process in the aim of getting something out the door can cause major headaches later on. Most importantly, it shifts the responsibility for quality assurance from those writing and implementing the code to the end users, who may not be experienced in understanding why things are going wrong – and may not be particularly patient in trying to figure out what’s failing. 

“It's too easy to ship crap and it's too easy to update that crap,” warned Scott Hanselman back in 2015. “When I started in software we were lucky to ship every six to nine months. Some places ship every year or two, and others still ship once.”

Move fast and hit moving targets

What’s often forgotten is that Facebook (as it was called at the time) updated its motto two years later. There was a recognition in the slight change in language about the perils of moving fast and breaking things. There may well be a time when you can break things, but those debts will eventually come due, especially once you have customers who rely on your products. The mantra instead became: “move fast with stability”, but you don’t hear that as often.

Shortly after that change within Meta, startup advisor, builder and investor Zach Holman gave a keynote at a conference in London. “Move fast and break things is fine for many features,” he said. “But the first step is identifying what you cannot break.”

Certain things within the backend of software development have to work right, first time – and if that takes more time to dwell on the problem and ensure you’ve gamed out all the potential issues that could occur, so be it. At the time, Holman was working for GitHub, which pushed out changes constantly. “There’s good reason for that,” he wrote: “it's safer overall. Incremental deploys are easier to understand and fix than one gigantic deploy once a year. But it lends itself to those small bugs.” 

Take heart from the idea of moving fast, yes. But the advice from within the industry is to swap out “and break things” with something like “and test often.”