How to Fail Well

We all have that dream – you check your homework schedule, and you’ve done all your homework for three of your four classes, but then you completely forgot about that other class (for me, it’s always English class) all semester, and you are going to fail out of school. We are trained to always view failure as life-ruining events. It doesn’t have to be that way – a little bit of failure is not only helpful, but vital to learning and growing as a person. It requires some work to make failure OK, but there are three steps that help make failure valuable – making failure cheap, making the way you failed informative, and adjusting course based on previous failures.

Make it cheap

When we have “that dream,” we wake up worried that we’ve lost everything we have worked towards. It doesn’t have to be that way – there are several things that you can do on software projects to make failure fast and cheap. Some of these techniques are more technically focused, the others are more business focused, and when everyone working on a product understands the different ways to fail faster, it can only help the product development team.

At a technical level, engineers have several tools that help with making failure cheap. One such tool is source control – there are many good examples of such tools. Using source control, if I develop a feature on my own computer and I do it completely the wrong way, I can easily make note of what I have learned and back out my changes to start over again from scratch, losing only that time. Another tool is automated testing, whether in the form of unit tests or acceptance testing, which provides a way of checking the code really quickly for problems, and letting us know about these failures minutes after they happen instead of weeks. Having a way to automate builds and deployments is another crucial step in making failure easy. If a developer or tester (or better yet, a product owner) can fire up an environment with a certain version very easily, then the team generally is more willing to try things out, see what works and what doesn’t, and adjust accordingly. When deployments are expensive, you don’t experiment, and you don’t learn.

At a business level, certain business processes can make failure cheaper. The simplest one to adopt is the developing a minimum viable product (MVP). MVPs provide sanity checks for the riskiest parts of a project, and give the business a way of deciding if a project is worth continuing to fund. Another business practice that makes failure cheaper is continuous deployment. Although continuous deployment requires IT and Operations support to accomplish it, it is more appropriately seen as a business process because it fundamentally changes the way that a business looks at their product development. If the business comes up with a new feature that takes three days to implement, then with continuous deployment it can be in production in three days (instead of three months!), and the business can figure out what value the feature brings to a customer much sooner than with a traditional release cycle.

Make it informative

When I have “that dream” about failing in class, I always have the same feeling: I have no idea how I forgot that I even had that class. Failure is made worse by not understanding it, so to make failure acceptable, it needs to be informative.

Games such as Twenty Questions or Guess Who make use of the principle that to identify a solution you should ask questions that give you as much information as possible. The best Yes/No questions split the solution space in two. Take this example: in Guess Who, there are more “men” cards then “women” cards, and some of the men have facial hair. When asking the first question, it is therefore not optimal to ask if your opponent picked a man (or woman), instead you should ask if your opponent picked someone with facial hair, since this splits the population in two. The same principal applies in learning about a new software project – early in a project, design decisions (either at a technical or a business level) should be done for the purpose of learning as much as possible.

When we are learning, either by ourselves or in a team, failure can be very valuable if we get a lot of information out of the failure. Whenever there is the possibility of failure, it helps to think in terms of the scientific method – form a hypothesis about what you think is going to happen, and then build the system to test the hypothesis. The hypothesis therefore has to be falsifiable – there has to be some objective way to know if your hypothesis failed or not.

Make it history

My college track coach used to tell us it’s OK to make a mistake once, but you better not make the same mistake twice. Mistakes are good if you learn from them, but if you fail repeatedly for the same reason, then that’s something different.

There are several ways to learn from past history. In agile development, teams use a retrospective at the end of an iteration to discuss what went well and what can be improved, to establish  actionable items that the team can do to improve and and to appoint owners of those items to ensure they get done. At a smaller level, having a coach, mentor or peer give you feedback about how a particular task or stretch of time went plays a similar role.

Keeping some kind of record, such as a professional journal or a team wiki, of all these shortcomings can also help you to remember why you (individually or as a team) do things a certain way.


It is a fact of life – we all fail. Learning from failure is important, but it doesn’t happen magically – the teams that benefit the most from failure are the teams that are prepared to benefit from failure. A team that anticipates certain kinds of failures and makes those failures very cheap is going to beat a team that pays more to make the same kinds of mistakes. A team that fails intentionally in a way to learn more will develop a winning product faster than a team that does not. A team that puts infrastructure in place for learning from history, such as having retrospectives every two to six weeks, will improve faster than a team that continues doing things the same way it always has.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s