When it comes to solving problems, there are two main lines of thoughts:
- Plan, plan, do
- Do, learn (repeat)
I’ve found during my life experience that the second method is almost always the best one. It arrives at the solution quicker, and it solves the problem better.
In this post, I’ll explore why that is – how iterative problem solving actually works.
Solving math problems iteratively
During homework one day when I was a kid, I discovered that I could more easily solve my math problems by just testing and seeing what would happen. Even if I had no idea what would happen, I simply started jotting down a solution – with no idea as to whether it would hold or not.
What I discovered was that the problem of “just trying something” would yield a solution far quicker than thinking ahead.
I proudly announced my discovery to my teacher. I don’t know if she really understood what I was talking about, but she applauded me nevertheless, encouraging me to keep doing what I did.
This approach to problem solving has stuck with me ever since. Now, I’m at a point where I will explore the mechanisms behind this type of problem solving to understand when and where it can be applied. In order to do that, we have to look at the mechanisms that makes this work.
How iterative problem solving works
In the situations where iterative learning works, what happens is as follows:
You have no clue what the solution is, but you do have some (far from correct) ideas or guesses or assumptions.
So based on these ideas/guesses/assumptions, you test a quick and dirty solution. What you arrive at is probably very wrong, but you will have gained something immensely valuable: Learning.
By testing your ideas, guesses and assumptions very quickly, you will see the actual results they yield. This is feedback, which gives you learning.
This, during the process of trying and learning, the amount of additional learning you will have gained will probably be far more than what you would have concluded/learned if you tried to figure out the “correct” solution without getting your hands dirty to actually try immediately.
Using those new learnings, you will have revised your guesses, assumptions and ideas, and you can try again. This time, from a higher level of understanding.
By repeating this process, you will continuously increase your learning until you are at a point where your assumptions, guesses and ideas are correct enough to bring you to the solution.
A formalized iterative learning process
Actually, learning IS making an assumption (read: guess) based on what you do know, then testing those assumptions to see if they hold.
So in your original “try and learn” approach, you might have tried to solve the problem by assuming (read: guessing) three things: Assumption 1, Assumption 2 and Assumption 3 (A1, A2 and A3).
If the assumptions produce the correct answer, great! You have verified that all three assumptions are correct.
If you get the wrong result, at least one of the above assumptions must be wrong. This, in itself, is valuable knowledge, because it presents you with two choices:
- If you have other ideas (for example A4 and A5) which you think are likely to produce the correct answer, simply try to solve a problem again using these.
- If you don’t have any more ideas, or if you have too many possible ideas to test, then you might want to drill down to A1-A3 to draw additional learnings about why they failed.
Number 1 is easy: Simply repeat the process.
Number 2 will create a “recursive iterative learning” cycle.
Recursive iterative learning
Pick one of your original assumptions to drill deeper into, for example A1.
Formulate sub-assumptions that underlie A1. For example, you might have some ideas (assumptions) about why A1 can’t be correct: Let’s call these A1.1, A1.2 and A1.3.
Pick one of these sub-assumptions, preferably one that would lead to some “chain reactions” in terms of your original solution (i.e. if any of them are correct, then it would also eliminate or strengthen some of your other assumptions). Then test it.
If it succeeds, great: You have learned something new. This new learning will have consequences for at least A1 (striking it from your list of possibly correct assumptions), and possibly more.
If it fails, repeat the process by testing the other assumptions in this level (A1.2, A1.3 and so on), or create new sub-sub-assumptions and test the sub-sub-assumptions (for example A1.1.1, A1.1.2 and so on). Do this until you can draw a definitive learning, and go back in your recursive learning chain and let all the recursive learnings fall into place.
You have now drawn a set of learnings from your original guess. From these new set of learnings, you can make new assumptions that are closer to the truth, test them, and repeat the process. With each iteration, you will come closer to the truth until you finally arrive at it.
What it looks like in real life
In reality, nobody (I hope..?) thinks like the above. Instead, the process happens unconsciously when we just “try something”.
For example, let’s take the math problem I was trying to solve as a kid described above. Here’s what actually happened:
I was sitting and looking at the problem, with no clue as to how I was supposed to solve it.
So instead of sitting there, stuck in my own thoughts, I decided to simply jot something down. I started by drawing a character, and then the next character. Before I started the process of jotting down each character, I had no idea which character would actually be “jotted down”. Instead, the actual character came to me as I started jotting.
A couple of times, I realized that the character or formula I jotted down didn’t make sense (=> my first iterative learning, happening organically). So I erased, and tried again (using the learning from the previous step to try something new, i.e. realizing that A1 didn’t work and trying A2 instead).
At some point, I thought I had arrived at the correct solution (using A2). But I realized everything I had done had been garbage, because it didn’t turn out the way I wanted it. I started wondering why the heck it didn’t work. I had an idea (A1.1). So I started experimenting at the side trying to answer the question in my mind as to why my original solution didn’t work (testing A1.1). Suddenly, I got an interesting result (proven A1.1) which gave me a new idea (A3) which I used when starting with the original question from scratch (testing A3), which arrived at the correct conclusion.
In reality, the process is even messier than this. But the actual process is the same, only more complicated (more branches, more assumptions and sub-assumptions), not different.
A couple of scenarios in which you can apply iterative learning
So where can you actually apply “iterative learning”? Well, as it turns out, in a lot of places:
Programming: Trying a solution and seeing where it leads you, drawing learnings from that destination and trying again (Agile Software Development)
Starting companies: Start from where you are, using the knowledge you have, make a quick and dirty roadmap, start the journey, and learn and adjust as you go (Lean Startup).
Building rockets: Build a rocket as quickly as you can, using what you know (A1, A2 etc.). When the rocket crashes, analyze why it crashed, draw a new conclusion (A1.1), make a new assumption (A3) and build another one. (Elon Musk’s methodology as described in this biography)
And probably much more 🙂
Summary of iterative learning
So in summary, when you have a problem, even though you know that you don’t know the answer, simply assume things and get started. Then learn from the results you get, and start again with the higher level of knowledge you have. And so on, until you have ruled out all but the correct solution.
One response to “Iterative Problem Solving”
Based on a conversation with a friend, I’ll add the following points to the post:
You can see the solution to a problem as a tree structure where each node is a way down towards the solution (hopefully) – but you don’t know before testing which way down will produce the results you are hoping for.
The road you choose to take is based on your assumptions (A1, A2, …). You always have a list of active assumptions (probably just intuitively, not explicitly), and a list of falsified assumptions (which may well be forgotten, not held in memory). The falsified ones are falsified because you tried a road down from a node based on some assumptions you had made, and when the road failed to produce the results you expected you assumed that your assumption was wrong. You then either create sub-assumptions (A1.1, …) to learn why A1 didn’t work, or you simply tried another node based on new/revised assumptions.
The fastest way to find the goal is NOT to try to build the entire tree or all assumptions at once, but to simply build/refine both the tree and your assumptions as you go. Make a very quick “best guess” based on your current knowledge and intuition and start executing any node that fits reasonably well. As described in the blog post, this makes you learn quickly and find the correct assumptions (and thereby the correct road – or even the opposite way around) quickly.
The mistake people make is that they try to draw a complete tree stucture before even trying to execute a single node. What happens then is that either they never finish (hence never start executing and thus never reach the goal, because drawing the “perfect” tree is very time consuming or even impossible), or if they finish they have to revise the entire tree after the first attempt at execution since the first things they will learn will invalidate their entire tree since reality is almost always different than you imagined.
I also think that another very important factor for success (aside from testing early) is: have the courage to make definitive conclusions even based on limited proof. In other words, dare to strike nodes that don’t work quickly, and dare to draw up new nodes that you believe in early.
I made the mistake for a long time in my life that I was too careful about making definitive conclusions. Instead, held too many nodes open for too long, thinking things such as “perhaps what I did didn’t work because I didn’t do it well enough / need more training / missed a detail that will make it work / …”. Rather than simply “It didn’t work, it probably doesn’t work, I’m going to try something else”.
The result of such reasoning is that progress will halt. In reality, there are so many nodes, and so many of them leading to the goal even though they are completely different and even contradict each other, than there is no “perfect way” – there are just multitudes of “good enough” ways. If you are slow with “closing off” ways that didn’t work, you will also be slow to find a way that works. The fastest way to find a way that works is to test many ways quickly rather than to try to “prove with high significance” that a way doesn’t work before you move on.