Working with Failure

The monitors I "repaired" broke again last night, as did the music light I'd "improved." In the morning, I bricked a $60 flash drive. And I also failed to repair my old coffee grinder.

But I'm not depressed or upset. Failure is part of the build cycle. It is why we work incrementally, why we test. And it is one of the basic elements of the Maker mentality; permission to fail.

Today I revised the music light circuit and it is working fine. Fixed the monitors after the show, and after bricking the flash drive made use of the broken parts to test a different way to connect into one; a solution I am confident enough with to use for the next flash drive. And I bought a new coffee grinder -- but my repairs lasted long enough to get me a couple much-needed cups of coffee.



A concept I've been thinking about lately is that problems occur both singly, and in plurals both series and parallel. The series ones are often the worst ones; hardest to track down, and most dangerous when they happen. That's when two totally different things have to go wrong to create a massive failure that is more than the sum of the parts.

I just went through two cases of parallel problems, though. The monitor system was wired wrong and the amp was going into thermal shutdown. And, as it turns out, the wiring to one of the individual speakers was bad (this bleeds into the serial class of problem since the bad wiring was not a serious problem until all the speaker wiring passed through the bad connection). In the other case, I had bad ground on a cable, and a noisy amp; two more-or-less independent speaker system problems each of which produced a frustratingly intermittent hum.

One of the basic tools of the engineer is to divide and conquer. Make a system into smaller systems and test each smaller system. Isolate the place where the problem is, instead of trying to deal with a complex system all in one shot. But, unfortunately, an entire class of problems only arises in the interactions between parts. This is why, among other things, systems integration tests are so important!

(Which is why the most recent test on the Holocron was if having the charger in circuit and the Trinket and Neopixels operating would interfere with normal file access on the thumb drive. They did not.)



Embracing failure is central to Maker philosophy. If there was a standard it was reacting against, it would be the idea that you have to be perfect in order to do anything. That you have to practice and practice, and get proper instruction, so when you finally sit down to repair an engine or paint a painting you do it "correctly" the first time.

The entire Maker outlook is of knowing you don't know what you are doing, going into it in an experimental attitude, and being prepared for a lot of things not to work the first time. Or maybe even the fiftieth time. Because, among other things, a Maker is not learning to do a craft exactly to the standards of the masters (with the only outcomes then being either you did it right, or you did it wrong), but doing things that have never been done before. (Or that have only been done by a small number of experimentalists).

The tricky thing, of course, is knowing enough not to injure or kill yourself. Going forward with a project with nothing but a basic familiarity with concepts and crowd-sourced intelligence is a way to discover tricky principles of science that can seriously mess up your day. Take TechShop, for instance; the basic classes give you about enough to turn the machine on and not have your hands actually on the spinning blades. Not enough to understand the hidden hazards to you and the equipment.



When you can, of course, fail well. Fail in a way that doesn't get you hurt. Fail when there is still time or money to recover (try to fail on practice pieces and trial runs rather than on your only piece of material). And learn from the failure. Unfortunately there isn't always time for forensic engineering. Often you have a Cosplay convention or a show opening or some other deadline and it is more important to get it working than find out exactly what it didn't.

Trouble is, of course, if you don't know how it failed, you don't know if you actually fixed it. That, if nothing else, can be the most satisfying aspect of a good failure. Sure, you failed. But you know why. And the next one will be better.