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.