Move Fast, but Don't Break Things.

Let’s talk about “Move fast and break things.” First of all, Facebook itself changed its motto to “Move fast with stable infrastructure” in 2014. So much for breaking things, at least if you’re a soulless corporate behemoth. Even if you’re a startup, though, breaking things makes no sense at all unless you’re talking about breaking the status quo in a moribund product space. Who has time to fix broken stuff?

“Move fast” is more interesting. Fast gets you two essential things: you get revenue sooner, and you get the feedback you need to ensure you’re building something the market actually wants.

“Move fast” doesn’t mean: get low-quality buggy garbage out the door faster. That slows you down. Every change to buggy code is painful (and time-consuming), particularly when you have no tests because you have “no time to write them.” You have no time not to write them. The best way to move fast is to increase quality and be serious about testing.

Also, buggy systems drive customers away. No startup can afford that. Bugs erode trust, and attempts to regain that trust by releasing a slightly less buggy version in a month are doomed. People have long memories.

There are constructive ways to move fast, though. The first is to change the way you work. Traditional Lean thinking—remove waste; work on one thing at a time (reduce WIP to 1)—cuts development time in half or more. Working collaboratively (e.g., mob/ensemble programming) eliminates coordination and integration overhead. Whole-team development—where all the skills needed to get something out the door are available within the team—eliminates dependency delays.

The next set of speed improvements comes from not building infrastructure you don’t need. If you have 100 customers, for example, you probably don’t need a database—a flat file with JSON in it will do. You almost certainly don’t need that slick UI (you need a good UX, but you can often get that with a very simple UI). You do not need an architecture or infrastructure that supports 100,000 users until you have 100,000 users. You do need an incremental-friendly architecture—one that can evolve as it scales. Eminently doable, but it’s a learned skill.

The most dramatic speed improvements come from not building entire features that nobody wants. Work very small to get code into your customer’s hands as quickly as possible, and then get feedback from them in a continuous conversation. Why build things nobody cares about? I’ve often released a small thing devoid of most of the features and bells and whistles I thought I needed, and the feedback was “this is great!” At that point, I’m done. Those bells and whistles were cruft. Build the thing that alleviates the most pain first, then get feedback.

So, I’m not sure about breaking things, but moving fast is always a good idea. You just have to go about doing it sensibly.