The Fallacy of Move Fast and Break Things

As to MFABT, the proper adjustment of that knob in a particular situation is difficult and is what expertise is all about.

The academic attitude is appropriate for critical systems and to a lesser extent for systems that can't get realtime updates, but if your app is non-critical (especially entertainment apps a la social media) and you can roll out a fix in a couple of hours, moving fast and breaking things is perfectly fine, especially for features which don't constitute core functionality. In the saas world, bugs are typically very cheap (or can be made very cheap via continuous deployment, microservice architectures, etc) and opportunity costs are through the roof. In that sense, moving fast and breaking things is probably eminently desirable, since it's cheaper to react to a bug than to delay an opportunity because you want to do quality assurance as though your software updates need to be mailed to users on physical media.

If a fishing ship goes out to sea and fails to catch enough fish or is wrecked because of a storm, it affects the families of the crew and everyone else who depended on them.

If Michael Jordan fails and misses the game-winning shot, it affects his whole team. If it's losing a playoff elimination game, it affects the workers at the sports arena because they don't the get the income from extra games.

> With MFABT the party doing the breaking isn’t often the one suffering from the breakage

I don't know about every company that's (misusing) MFABT but with Facebook, it was their mantra before 2012 when they were not making any profits and trying to survive while competing against the bigger website, Myspace. Their software engineers could have conceivably broken their website so badly that FB goes out of business. That's what happened with Knight Capital when they misconfigured a server and lost $450 million.

MZ's aphorism is just a twist on a common observation about making progress. He expanded on it in an interview:

>We've optimized so much of our culture around just making it so that people can come and build things quickly. Whether it's everything from having the right tools in the right development environment to build things quickly, to nightly code pushes, hiring the best people who have a bias toward just pushing things very quickly, very entrepreneurial. The whole culture is tuned around that. And I think there's probably something in that for other entrepreneurs to learn which is that making mistakes is okay. At the end of the day, the goal of building something is to build something, not to not make mistakes. [1]

He actually does not want a broken Facebook system. But he also knows that if there are no mistakes, it means the team is not bold enough with adding features. Yes, they could die from a broken code deployment to production servers. But they'll also die if Myspace or Google+ is more aggressive in adding social networking features. Being ultra-conservative just to "avoid breaking things" will mean the business can go bankrupt and thus, there's no website to even worry about breaking.

[1] excerpt from: https://theweek.com/articles/462863/stories-behind-3-great-b...

* We don’t know what the final solution will look like, because of things like scope creep and client demands.

* The more agile the team is, the higher the velocity and ability to iterate.

* The more specialized roles we have (like project manager, team lead and junior developer) the more we can focus on completing tickets to increase velocity.

Which I counter with:

* We actually do know what the final solution will look like. I normally have an idea of what clients are asking for before they finish their sentences. Then I extrapolate to the fundamental problems and meta concepts around their specific problem. I’ve already formulated solutions and am solving them in my mind, until I isolate the unknown steps (the hard steps), whose odds of me being able to solve them are the basis of my estimate. Most of my work today goes into research, setup, glue code, infrastructure and maintenance. Solving the client’s actual problem constitutes perhaps 5% of the work I must do.

* We can always iterate faster in our minds than in the real world. With a proper architecture budget, we can take time in the beginning to brainstorm the complete solution before we ever start writing code. Then if we follow proper quality assurance practices like test-driven development, we can write code that is free of technical debt and bugs. All the while exerting substantially less effort than writing the same thing several times.

* Agile programming wasn’t really a thing until the rise of large internet companies and the marginalization of individual software developers. It’s curious to me that the people with the most say in writing solutions have the least clout in organizations. I feel that this is due to supply-side economics and wealth inequality. So today we cater to client first, then organization, then software developer. That’s what the specialization in agile is really all about. But we should be doing something more like movie production, so the client is the producer, the organization is the director (or movie studio) and developers are the actors. The industry should have more confidence in the process and have conventions which mitigate the churn caused by clients’ fickleness and low understanding of the problem domain. But right now it feels like the emphasis is on getting every scene filmed as fast as possible. We pretend that developers have no gravitas and are just interchangeable cogs in the machine. It’s no surprise to me that most productions bomb in the box office.

To use construction as an analogy: programmers used to be akin to architects, spending time in the beginning to draft a plan that includes all contingencies so that the building doesn’t fall down (a right-brained or politically-blue approach based on creativity, insight, seeing outside the box, etc). Today we’re being told to be framers, hammering out solutions as fast as we can over and over again in order to get things done until the building is finished (a left-brained or politically-red approach based on a strong work ethic, discipline, loyalty, not getting distracted, etc).

I think these are both important, and over the last year I have been working on my “getting things done” side to improve my execution ability. But I will always be a dreamer and value the intuitive side of software development. The idea that we can manifest solutions in the real world with the power of our minds is what got me into programming in the first place. The trend towards application and turning programming into just another job has soured me on the field in general. I’m actually not entirely certain that I can do it anymore. So to me, the true cost of move fast and break things is the loss of people like me who thought that this was all going to go a different direction.

"Break things" is objectively an imperative. There's no hyper-literal or otherwise careful parsing necessary to arrive at that realization. It's the default.

Careful thinking is actually what you need to arrive at the more useful non-literal understanding. And unfortunately the phrase itself doesn't encourage that.

Something like "Move fast, even if there's risks" or "Prefer momentum over risk aversion" would be the face-value formulation.

> We're just humans playing with language

And being played with by language.

If language is powerful enough to orient someone on the benefits of preferring momentum over risk aversion, it's powerful enough to distract from the threshold where there's inadequate anticipation of consequences.

Any given formulation may do one job better than another.

MFABT is not an optimal expression. There are better ones.