photo by Sean MacEntee : flickr.com/photos/smemon

Move Fast and Don’t Break Things

A prototyping manifesto for software engineers

“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:

1. You’re terrible at estimating. One day for the easy case, two days for the edge cases, two days to deal with the integrations you forgot you needed, and one more day for testing. If you’re lucky.
2. Both your codebase and your design are paying the cost of increased complexity, even if you build it perfectly and on schedule.
3. Your change has to be supported. Did you tell your support team? Is the new feature fully documented? Oh hey, looks like your tutorial videos are out of date.
4. Are your customers going to be pissed off that you changed your interface yet again?

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:

• Building without the constraints of your product’s current architecture. Ignore the elephant of the software you’ve already written.
• Building only the parts that matter for this investigation. Do you need a functioning login screen to test a new notification design? Probably not.
• Building each component to the necessary level of fidelity and no further. Does the animation on that menu matter? If so, build it. If not, skip it.

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.