Hacker News Reader

Comment by blacktriangle | Hacker News Reader

The problem with failure is there are infinite ways to fail. So from a pov of looking to reduce my chances of failure, reading about a failure means there are now Inf - 1 ways I might fail, not too useful. Pragmatically reading about success and seeing if I can repurpose their techniques to my situation is far more useful.

Where reading about failure is useful is to help remove the general stigma around failure that prevents people from even trying, but there's only so much of that form of self-help a person needs before they move on.

View on HN

>The problem with failure is there are infinite ways to fail

Do you mean infinite ways in life? I’m trying to reconcile your statement as it would apply to a specific domain rather than something as broad as the scope of ones life.

Reliability engineering would tend to disagree with the above quote. For a specific engineering application there are a certain number of fault modes that can be ideally mitigated and quantified as a reliability risk. Good engineering practice documents these in the form of fault trees, failure mode effects analysis etc. Sure, unknown failure modes still may pop up, but to the point of the article, if they get discussed and documented they can be mitigated in future iterations. While maybe never reaching zero, over time the remaining unknown risks become smaller and smaller probability events.

I was thinking of it more in ways businesses fails given we're on HN and that's a bit more narrow than the "in life" version of the article so that it's more useful.

However that's a really great point that in the context of a specific engineering application failure can be enumerated to the point where such study of failure is incredibly powerful. Thanks for pointing that out.

Businesses also have common failure modes. I used startups as an example of learning from failure in another comment: https://news.ycombinator.com/item?id=26498875.

If you read these 13 stories of failed software products that I collected you'll see that they have quite a lot in common: https://successfulsoftware.net/2010/05/27/learning-lessons-f...

Also, hanging out on forums for software entrepreneurs, I see people making the same standard mistakes again and again.

can you tell me some of them?

Off the top of my head:

Not doing market research.

Taking too long to release v1.

Not spending enough time on marketing.

Lifetime licenses.

Obsessing over piracy.

You also need to read about failure to account for survivorship bias.

Eg, did some entity fail even though they were doing the same things as the successful entities?

If you detect that, then it's evidence that the techniques of the successful entities are no guarantee of success. That some other technique or factor or luck was the actual differentiator.

That's useful information when you're trying to decide what techniques of successful entities may be worth repurposing to your situation or not.

Not so many ways to _recover_ from failure and go on, though.

That's usually seen as success though.

I'm fairly confident in saying no success has come without recovery from failure

It may not be something you can publish as success, though.

The lesson is: failure is an indespensable step towards success, so we need not to gloss over failure as if it's taboo

    Perhaps your purpose in life is to serve as a warning to others.

Actually, there are only finite ways to fail. It just happens to be a large number. Thinking of interactions of the world as propagations of signals and considering Kolmogorov-style descriptions of entropy would lead one to this conclusion of finiteness. See: "Kolmogorov complexity"

Further, there are a finite number of patterns of failure, which is of course less than the number of absolute ways things could fail.

The biggest detriment is not that things can fail, but that people get overwhelmed by believing that such things are infinite in scale.

As an example, there are only 16 categorical manifestations of software exceptions based on the following categories:

- Synchronicity, Scope, Origin

For Synchronicity we have:

- Synchronicity

- Asynchronicity

For Scope we have:

- Process-specific

- Cross-process

For Origin we have:

- Data origin

- Temporal origin

- External origin

- Process origin

Then you combine them such as "Synchronous-CrossProcess-Temporal Origin." The total is 16 ways. Even if something were somehow to be missing from this categorization scheme, it would only add a finite amount of possibilities to the permutations. Yet this taxonomy seems quite complete as is.

See: “Error Handling in Process Support Systems” by Casati & Cugola.

If the context isn't a formal proof, you can safely substitute infinite with 'might as well be infinite' most of the time to get the intended meaning.

There are categories of failure though. Those not only tell you where to look but give you starting points and substitutions.

Substitute one set of problems for a better known set, and go from there. When engineering figures out how to solve the less known set, then you can do something “new”.

Today you might solve liquefaction by running pillars to bedrock and then design for earthquake damage caused by being anchored to bedrock.

Some day you might use the Dutch trick of building houses that can float instead.

You can derive pattern though. You can learn about recuring weak links. And you can learn about solutions. Those are nice.

Reminds me of a quote from Tolstoy: “All happy families are alike; each unhappy family is unhappy in its own way.”

Like most proverbs, it only seems insightful and true if you don't think about what it is claiming at all.

Reply on news.ycombinator.com