Fail fast, fail hard, fail safe.

In test-driven software development, we write automated tests for all of our code. On a large project, the full test suite might take a while to run, so we run the tests which are most likely to fail earlier. That gives us important feedback sooner. Fail fast.

In Agile development, we plan to build the riskiest parts of the software first. If we’re writing Netflix, we prove that we can recommend movies well and interface with the mail fulfillment center first. If we fail early, we’ve got more time and more budget to try something else. Maybe we even need a different business model. If we fail after we’ve spent months on the login page and picking a shade of red for the background, we’ve wasted time and money.

  • Fail fast. Don’t waste time doing things you know are going to succeed but might end up being worthless. Do the riskiest thing first.

  • Fail hard. Give it to me straight, doc. If our business is going to fail, let’s really find out. If we break our current model hard enough, we might find a better one. If Netflix couldn’t get algorithms to recommend movies, they might have built a social network to let your friends recommend them.

  • Fail safe. Fail while failure is still an option. Fail before you promise people you won’t. Fail while you can get out alive. And always be looking for a backup plan, just in case.

This isn’t just for technology, and it’s not just for business. This is for writing a novel. This is for shooting a movie. This is is for anytime you take a risk with a due date.

3 Responses to “Fail fast, fail hard, fail safe.”

  1. I love it. This kind of agile thinking applies to my Think, Try, Learn work. When trying something new it’s all too easy to get caught up in getting it perfect. “Extreme Experimenting”? Good stuff, Peter.

  2. Mike R says:

    To me, it’s horse-hockey to say that the only way to find out “if something will work” is “to attempt to build it and then die trying.” If people built houses that way, there would be no houses.

    A far better approach is … “fail to plan, and you plan to fail; therefore, plan.” Houses are built scrupulously on-paper before a single foundation block is laid.

    (1) Instead of “fail fast,” don’t do things that “might be worthless.” Figure out whether they will be or not, before you do anything.

    (2) Instead of “fail hard,” figure out whether your model is going to fail and don’t build it at all if it won’t. Determine whether or not an algorithm can or cannot recommend a movie. Don’t “do” anything until you know whether it can or can’t.

    (3) Instead of “fail safe,” determine in advance whether failure is likely to occur and do not commence work if so. “Failure is never an option” to the guys who are forking out the dough. Don’t promise anything to anyone until you know you can deliver, and until you know exactly how long it will take.

    The premise of “Agile” (and “Extreme”) is that you can’t know the results until you try (and fail) to do them, and it is also that the folks who are shelling-out the cash to you are willing to do so indefinitely, even though they still don’t seem to have a house to live in. Trust me: they will start asking you, “HOW do you know?” And you’d better have an answer much better than “Real Soon Now… Trust Me.”

  3. […] Mike R left a great comment on the post Fail fast, fail hard, fail safe. Because it got so big, here’s my response: […]