A Multi-Modal Approach To Solving Extremely Difficult Problems, Part III (Massively Iterative Failure)

Designolution.

In Part I and Part II of this series, I explored radically different approaches to problem solving, including:

The Rational Approach
The Empirical Approach
The Subjectivist/Attentional Approach
The Intuitive/Super-Conscious Cognition Apporach
The Holistic/Network Analysis Approach

Too often we fall into the trap of thinking about a problem in a single way, and come up short because our habitual thinking mode isn’t best suited for the problem at hand.  For example, if we try to to apply an empirical problem solving approach to a situation that is in massive flux, we may find that our data regarding what has worked in the past to be useless (aka driving forwards while looking out the rear window).

Another vulnerability of empiricism is the likelihood of discounting the possibility of low-probability/high impact (black swan) events.  Just because an event has never happened (and has therefore never been observed) doesn’t mean that it can’t happen.

I don’t mean to pick on empiricism.  The rational approach has its own weaknesses (one weak premise throws off the whole argument).  Rationality has a dismal record when applied to complex multi-variable systems like human beings.  People act impulsively and emotionally as often as they act rationally (insert punchline about economic theory and bankers here).

My point is that we need a multi-modal mental toolkit to be able to tackle the most difficult problems.  We need to be flexible, non-habitual thinkers, capable of devising empirical strategies, deriving logical solutions, being sensitive to intuitive flashes of insight, and perceiving hidden networks that influence the situation.

The Evolutionary/Massively Iterative Approach

Evolution solves problems via iterative brute force.  It’s not that evolution tries everything — solutions are limited to tweaks (mutations) of previous versions — but a great number of variations are tested.  Biological evolution works pretty well.  Millions of radically different lifeforms thrive in a multitude of environments.

Definite choking hazard.

Evolution also has a major weakness — because of the more-or-less random approach to variation, many “solutions” (lifeforms) end up with major design flaws (which makes sense when you consider there is no designer).  That’s why human beings don’t have separate tubes for breathing and eating, an unfortunate feature of our phenotype that results in thousands of choking deaths annually.

Still, evolution is an immensely powerful process, and we can mimic it as a problem-solving approach.  There are two ways to do this.

The first way is to build a evolution simulator specific to solving your problem.  A great example of this approach is this car design evolution software.  Each generation tests a novel mutation, which is tested in the simulation.  The more “fit” iterations (based on how far the car goes) are further mutated and re-tested.  Eventually, something proximately a functional 2-D car design emerges.

Virtual speedster.

Antenna evolved from a non-branching genetic algorithm.

The advantage of this approach is that you will get many novel and effective “designs” that you would have never arrived at via a traditional design method (as in using your brain to think of things).  Evolved “designs” are often ugly, awkward looking, and just plain weird.  For example, check out this evolved antennae design.  It’s efficient, but strange looking.

If you don’t have the time or inclination to build genetic algorithm software to evolve a solution to your problem, you can also mimic evolution by attempting massive numbers of iterative solutions, and learning from your failures.  In most cases, this is how commercial software projects develop.  Certainly there is a “design” process in the beginning where empirical analysis (what has been observed to work in the past) and rational planning (what should work, based on a logical assessment of the problem) are used.  But during implementation, evolution takes over.  The clients/users provide feedback, the engineers respond with “mutations” to the software, the users provide more feedback, and so on.

This process results in the extinction of many software projects, and the survival of many more.  A few thrive massively and dominate their niche.

The main problem with evolved solutions is the difficulty of making radical improvements.  Sometimes a small tweak can result in a huge boost in efficiency or “fitness” of the solution, but small improvements are generally the rule.  If some fundamental aspect of the solution is deeply flawed, you can’t “evolve your way” to a fix.

This is very much the case with software design.  If, two years into implementation, you (the programmer) realize that the software you created would be much more efficient with a totally different data-structure or user-interface, you can’t make the changes without massively disrupting the project.  There is too much code written based on the existing design, and the users have invested too much time in learning the software the way it already operates.  If you try to fix the problem, you’ll break the software, lose the faith of your users, and kill the project.

This is called the fitness peak problem.  If you’re at a medium peak of fitness (your software works pretty well) and you try to get to a higher fitness peak (your software will work extremely well), you have to climb down your current fitness peak into the flatlands, the zone of your software doesn’t work at all.  This isn’t acceptable.  You’re stuck where you are.  You can’t get there from here.

When Massive Failure Is A Good Strategy

Failing big and failing frequently isn’t always a good strategy.  When the cost of failure is high (skydiving, for example), then you don’t can’t afford to fail at all.  If you experiment with a new parachute design and it doesn’t work, you die.

Testing a new chute design.

On the other hand, when you’re in testing-mode, the cost of failure is low.  If you’re dropping rocks out of an airplane that are attached to new-fangled experimental parachutes, it’s no big deal if one of the new designs doesn’t work.

In fact, as long as you’re extracting useful information out of each failed attempt, it’s probably helpful to fail a great number of times during testing.  The more rigorously you test your solution, the more you debug it, the better it will perform under “for keeps” conditions (live implementation).

In general, it’s good to fail a great deal while testing or practicing, as long as each failure provides useful information that can subsequently be used to improve the solution/skill/behavior.

If your situation is failure tolerant (you can operate is a low-stakes practice mode or test mode), then mimicking evolution can be part of a good strategy.  Make a change (any change) and try again.  Try holding the ping-pong paddle in your left hand.  Try working while standing up.  Try some new spices in your cooking.  Random iterations in a low stakes environment can be a good way to explore a solution space.

I say part of a good strategy because pure randomness, even when combined with selective filtering (this worked, this didn’t) will only allow you to progress slowly.  Unlike biological evolution, your “tweaks” or mutations can be informed by empirical observation, reasoning, intuition, and other cognitive processes.  We have brains — we should use them.

Pure randomness, behaviorally, is just flailing.  It’s trying to get to Shakespeare with a thousand typing monkeys.  It’s just not going to happen within a reasonable time frame.

The Music Business — Evolving a Hit

Songwriting has an evolutionary element.  Writers tweak melodies, rhythms, and production elements based on feedback from peers and the music market.  There are so many variables, both in creating a song and in the constantly shifting tastes of the music market, that an evolutionary approach is one of the few methods that can actually get you closer to your goal.

You can try an empirical approach to writing a hit — what kinds of lyrics, chord progressions, and production techniques have worked in the past?  The problem, of course, is that music tastes change quickly.  What sounded fresh last year can sound stale the next.

You can try to come up with a rational approach to writing a hit, perhaps by analyzing and defining a factor such as novelty.  Certain schools of music theory did just that; the result being music so unpredictable that the listener had no idea what note would come next.  In terms of popular appeal, this kind of music (mostly improvisational jazz) flopped.  It turns out listeners like a little novelty in their music, but they like to have some kind of idea where a tune is heading.

Some sophisticated musicians and producers can successfully use an intuitive approach to song-writing, and I think that’s probably what the best and most consistent hit-writers probably do.

Unstoppable hit writers.

For the rest of us, the non-musical geniuses (like myself), the evolutionary approach (along with a dash of intuition and dollop of empirical observation) is probably the next-best thing.  We try stuff, and we see what sticks.  We adjust course frequently.

That’s certainly the approach that Spesh and I take to running Loöq Records.  We explore the (Venn diagram) overlapping space of what we like, what we have access to, and what we think other music appreciators will respond to.  We tweak both our own song-writing, and the kinds of tracks we sign, based on feedback from our peers and the market.  While we haven’t released any massive hits yet, the rewards from our microhits far outweigh the costs of putting out music.  It doesn’t matter that most of our releases essentially fail (and the same is true for every record label) — those that succeed provide disproportionate benefits.  As long as we run lean, the cost of each failure is low, and the reward of each success is high.  It’s an ideal environment to evolve our way to success.

Summary

Using the Evolutionary/Massively Iterative Approach, either via the design and use of genetic algorithm software, or via mimicking biological evolution behaviorally is a good approach under the following conditions:

1. The cost of failure is low (and/or a “testing mode” is available).
2. Useful information can be derived from each failed iteration (feedback).
3. The evolutionary process can be accelerated with cognitive intervention (try the best options — don’t try everything).
4. There is adequate time to evolve a solution.