What is failing?

Note: See also, Alex Pineda’s (@alexpineda77) blog post on the subject.

“I have not failed. I’ve just found 10,000 ways that won’t work.”
― Thomas A. Edison

What “counts” as failing?

I’ve always had this idea that failure is something that happens in the later stages of a project. It’s when something doesn’t work that we expected would work for good logical and/or empirical reasons. It’s when something doesn’t go according to the plan, and there’s a non-trivial cost, even if it’s just time.

When you test the waters first, either with investigative data finding or prototypes, you can often figure out enough to avoid having this type of costly failure. Sometimes an idea is too big to investigate or test the waters first. You can only find out whether it works or not by trying it in it’s full blown incarnation. I suspect this type of problem is rarer than people believe, perhaps even much, much rarer.

I’ve most often dealt with the former type of easily investigated problems. As a result, I’ve never considered things that “fail” before the expectation based on good reasoning, before the plan, before the non-trivial cost, to be failures. They are just investigations with bad outcomes.

But strictly speaking, every prototype, every investigative data finding operation, still has some hypothesis behind it. And investigations and prototypes still cost time, just less time.

This may be true, and it may even be a variant of the “fail fast, fail often” idea that you see in design, invention processes, agile development and startups. If I start considering these things failures though, I suppose I have been “failing” all the time without even realizing it.

Still, I’d rather not call these things failures, just something I haven’t figured out yet.