There is no problem so complicated that you can’t find a very simple answer to it if you look at it right.
— Douglas Adams
If you’ve spent any time working with software, you know the frustration of having a problem that is difficult to solve. No matter how much you strive to find the right solution, it just eludes you.
In this Wizard, I will provide a systematic guide originated by the mathematician George Polya in his book How To Solve It. I will also include several other methods that I have personally found helpful when I am faced with problems that are just plain tough to solve.
Introduction
I first came across Polya’s work when I was studying advanced math a few years back. George Polya was a Hungarian mathematician who taught in Zurich and at Stanford University in the early to mid-1900s. One of his interests was problem solving. Although his book is largely math-centric, it is accessible to non-mathematicians, and I believe his approach has great value to software developers. Beyond that, his approach also has applications in normal day-to-day problem solving.
Polya's Approach
His method has 4 steps:
1. Understand the problem.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
— Abraham Lincoln
By implementing this seemingly simple step many folks can avoid wasting significant time. When tacking a tough problem, make sure the problem you are solving is truly the one that needs to be solved. For developers, this means spending the time to ask the right questions, tease out the important issues, and dig into some of the non-obvious situations that you may run into.
Ask also about the cause of the problem that you are trying to solve. Frequently there will be clues that will help you understand the problem in greater depth. This last part is especially important. It could be that you have been asked to work on solving a symptom rather than the true problem. If you can solve the base problem along the way, you will be a hero.
2. Devise a plan.
By failing to prepare, you are preparing to fail.
— Benjamin Franklin
After you have a solid understanding of the problem, you may want to dive in and start solving. Resist the urge – first come up with a plan. This step helps focus on a more direct route to the solution. You will not only have fewer wasted steps and back tracking, but also, if things don’t work out the way you expect, you will find it much easier to see where things have gone wrong.
Developers can achieve this by writing pseudo code for the plan steps, and then use the pseudo code as the inline commenting.
3. Carry out the plan.
This tends to be the fun part. You understand the problem; you have a plan. Now it is time to execute. On the software side, I encourage you to be generous in your use of inline comments. Documenting your thought process, will both not only to clarify what you are doing, but you will find these truly helpful three years downstream, when you need to make changes to your code.
4. Look back.
After you have successfully implemented the plan document, take note of the following:
- What things worked?
- What didn’t work?
- If you knew at the beginning, what you know now, what would you do differently?
- How could you have solved the problem more efficiently?
- Did you get any insights along the way?
- Did you write any code that has the opportunity for reuse? If so put it into your software toolbox.
Conclusion and a Look Ahead
In this issue of the
Wizard, I walked you through a high-level overview of Polya’s approach to problem solving, a method I have found valuable.
In the next
Wizard, I will expand on this and provide further details, tips, and techniques that I have used when the going gets really tough.
