The phrase “Move fast and break things” was famously coined by Facebook CEO Mark Zuckerberg. But why do people keep saying it?

I’ve seen this quote regurgitated by software engineers with increasing frequency of late.

And it’s almost become an excuse for lazy developers to somehow justify it’s absolutely fine to have bugs in their code.

Now to be clear, **ALL software has bugs**, that’s a fact.

It’s part and parcel of building applications. More so when you have several, hundreds or even thousands of people contributing to a codebase.

The problem is, **this ‘motto’ died years ago**.

At the company’s F8 conference in 2014, CEO Mark Zuckerberg introduced a new motto:

> **“Move fast with stable infrastructure.”**

It “may not be quite as catchy as ‘move fast and break things,’” Zuckerberg said. “But it’s how we operate now.”

“As developers, moving quickly was so important, we would even tolerate a few bugs to do it.”

![](https://hackernoon.com/hn-images/1*GUBHRJ5GBwh9NnUZ4bj2aQ.jpeg)

Now that Facebook has over 2 Billion users and a whole heap of advertising revenue to protect, breaking a few small things could have massive implications.

**_Today’s software engineering landscape is very different to the one we all knew several years ago when this phrase was first created._**

### The software engineering landscape has changed

Should a severe bug affect end users negatively, every company employee from the receptionist to the CEO, is not going to be pleased about it. The company brand is being tainted by problems you coded and then released into user’s hands.

Yet some developers believe it’s all justifiable, because they are shipping code at a rapid speed, showing great ‘innovation’ and somehow breaking things along the way is acceptable.

**No, it isn’t. Not anymore.**

![](https://hackernoon.com/hn-images/1*6SIS3lyCDsLLiW2SsO6C-g.png)

“I’m sorry. I was only ‘moving fast and breaking things’, sir”

The ability to speedily deliver software applications on a massive scale, while also maintaining consistently reliable user experiences is well within reach for every company.

Choosing between speed and quality is no longer necessary.

These days, you can move fast and fix things too.

### You just can’t fix what you can’t see

The answer to increased software quality is not to simply write more unit tests. It takes a change in mindset and attitude culturally within a software development team.

Bug tracking and resolution used to be an incredibly manual and unforgiving task. That’s probably why most developers see it as a huge pain in the ass.

Not only to have users report the problems they experience themselves, but to also log them all individually into a bug tracking tool. Allocating developer time to reproduce and fix them, with limited technical details.

_Ugh._

That’s where modern, dedicated, [error tracking tools](https://raygun.com/platform/crash-reporting) can ensure developers get a real time view into production errors and crashes their users are experiencing, and then have enough details to reproduce them in minutes.

[Raygun](https://raygun.com) is just one example, but there are many useful tools available to software engineering teams that keep a watchful eye on your applications in production, **then simply tell you when to pay attention**.

![](https://hackernoon.com/hn-images/0*zHRgAhMARWlD21gh.)

Developers are no longer blind to issues after code goes out the door into user’s hands. If you do break things, it’ll quickly be discovered before impacting end users.

### Debugging issues and fixing them is easier than ever

I’m sure you don’t code bugs into your applications intentionally, but there’s a lot to be said for being able to debug them as quickly as you write them.

During development and testing, you might be used to having things like consistent operating systems, devices, browsers and their respective versions on hand, plus be able to access full stack traces on each unhandled exception. It’s relatively easy to spot bugs.

**Once in production, everything goes dark.** None of this information is available to you and many bugs might **_only_** happen in production.

Without a monitoring tool that can collect these details, you’re simply flying blind.

With proper monitoring in place, errors, crashes and performance problems can be detected and delivered into team workflows automatically. A self populating to-do list if you will of things you can do to improve your software. Right down to the exact line of code an issue occurs on.

### Move fast, but fix your damn code, seriously

It’s actually very easy to move fast and break things when it comes to software development. Anyone can do it.

To be **_a great developer_** you need to care about your code quality and the impact you have on the users of your software.

It’s easy to shrug off problems with a ‘move fast and break things’ mentality. But we build software for our **_users_**, and sometimes forget they are real **_people_**.

They are human beings that get frustrated and angry when they can’t operate your software the way they need to.

In today’s modern development environment there is no need for companies to be exposing their users to undetected bugs. The [tools are available](https://raygun.com).

So, move fast.

Move as fast as you like.

But take pride in fixing things. Rather than breaking them.

Facebook

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

‘Moving fast and breaking things’ is such a load of crap

Too Long; Didn't Read

Company Mentioned

@nickharleynz

RELATED STORIES