Image for post
Image for post
photo by Sean MacEntee : flickr.com/photos/smemon

Move Fast and Don’t Break Things

A prototyping manifesto for software engineers

Jesse Kriss
Jul 19, 2013 · 3 min read

“Move fast and break things.”

“Fuck it, ship it.”

“Let’s just build it and see what people like. Deploy and iterate! We’re agile!”


People who say these things have good intentions. They want to build great software that people love using, without being overly constrained by process, rules, or bureaucracy.

Here’s the problem: it’s lazy, it’s wasteful, and it’s painful for the people who use your software. You have two jobs: make the right thing, and make the thing right. Building and shipping features without having confidence in either is a bad idea.

“But that’s the great thing about web development,” I hear you say. “It’s so easy that we can implement the feature in a day and then get it out into the real world and see what people think.”

The bad news:

The good news? There’s a better way.


It’s actually a really simple idea: don’t build it all first.

You may have heard about paper prototyping, and other kinds of low fidelity prototyping. The whole idea is that paper is fast, flexible, and can let you evaluate and refine ideas without all that pesky software engineering. (There are plenty of digital tools, too, but in my experience, they’re harder to use than paper without adding much benefit.)

That said, paper and visual prototyping tools only get you so far – you are constrained by their capabilities.

“Yes, exactly! That’s why I prototype in code!”

Sure. But are you really prototyping, or are you building the real thing?

To me, prototyping means:

Now get that thing in front of people: inside your group, inside your organization, and maybe even some of your customers. (And please, don’t just ask, “Do you like it?” Consider reading up on usability testing.)

A nice bonus: this is a super fun way to develop. You can throw away all the usual constraints and hack something together to test your hypothesis. You can probably build it in less than a day.

Now you can have some evidence that the thing you’re working on is the right thing. And if it’s not, now’s your chance to correct course.


“Wait. I thought the designers did the prototyping. Am I a designer or a developer?”

Here’s a secret: you can be both. Or, if you prefer, you can be a developer who makes better software in less time, or a designer who uses code to make really effective prototypes. That code gets you closer to the production implementation, either way.

I don’t care what you call yourself, though. What’s important?

You don’t have to write production code (much less ship it) to see if your idea is good.

You don’t have to build a complete solution to test a hypothesis.

And you can do better than “move fast and break things.” Leave the time, waste, and feature thrashing to inefficient startups with infinite software engineers and money to burn.

Thanks to @marihuertas and Tom Crockett

Jesse Kriss

Written by

Code, design, infovis, music. Current: Netflix. Past: NASA/JPL, OFA 2012, Figure 53, IBM Research. All rights reserved, all wrongs reversed. He/him.

Jesse Kriss

Written by

Code, design, infovis, music. Current: Netflix. Past: NASA/JPL, OFA 2012, Figure 53, IBM Research. All rights reserved, all wrongs reversed. He/him.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store