How to Solve It - Book review




"How to Solve It" is an excellent book by the mathematician George Polya in which he lays out the mental process of problem solving. He describes problem solving as a skill which can be learnt and taught. Polya gives a set of practices and guiding questions which he has found effective in solving problems and teaching students how to solve problems. I will summarize the book and follow with some observations about how it relates to Software Development.


Phases


There are four distinct phases to problem solving:

  1. Understanding the problem
  2. Making connections to create a plan
  3. Executing the plan
  4. Reviewing and discussing the solution



1.  Understand the Problem


The first phase is to understand the problem. What is the unknown, data, condition?

Draw a figure, introduce notation.

Is it possible to satisfy the condition?


Polya makes a distinction between
a) getting acquainted, and
b) working for better understanding.

The point being that it takes effort to examine the problem from multiple angles, and achieve a strong definition of what the goal is.

You should only start working on the next phase when you have a clear understanding of the problem that sticks in your mind without effort.


2.  Making a Plan


Making a plan in problem solving involves procuring a bright idea. Ideas are mysterious but tend to occur to people who work at them. They often spring from acquired past experience and knowledge.


Related connections - look for a similar unknown. The key task is to make many connections with related problems. There will be many to consider, so look for a similar unknown give focus on your problem.

There is an excellent book called "Where do good ideas come from?" by Steven Johnson which explores the source of ideas at an individual and macro scale. Johnson identifies a strong network effect which he illustrates by discussing coral reefs which support a teaming diversity of life unlike the swathes of empty ocean, dense cities like New York having a tendency to produce intellectual breakthroughs, and the internet opening up a stampede of innovation. It is interesting to see how similarly these two authors talk about ideas, but from very different starting points; Johnson searching for innovation in the large, and Polya coming from a formal mathematical problem solving perspective.

You can cultivate an innovative environment by:
  • Reading widely.
  • Taking an interest in varying subjects.
  • Spending time thinking.
  • Exploring combinations of existing concepts to make new ones.
  • Making a memory map of important thoughts and ideas for later use (there are software solutions to assist with this, I find keeping a journal works).

Good ideas occur in a fertile environment. Good mental habits are required:
  • Concentration upon the purpose - you want an idea related to your problem, so keep it clearly in your mind.
  • Create work for your background mind - your brain does amazing work while you are sleeping, you want it working on the right problem, and the way to do that is to consciously think about the problem you want to solve while awake.
  • Interest is required to do this, so look for ways to re-frame the problem as something interesting, and follow your curiosity.
  • Sometimes we get lucky.

Thomas Jefferson said "The harder I work the luckier I get."

Be deserving of luck by exploiting opportunities.

Louis Pasteur said "Chance favors the prepared mind."


3.  Execute the Plan


Patience. Check each step.



Polya recommends some strategies and guiding questions such as:

  • Could you use this idea?
  • Can you restate the problem?
  • Generalization/specialization/analogy
  • Try to solve a related problem
  • Did you use all the data?
  • Did you use the whole condition?
  • Construct an interesting example


With a plan in place, execution requires patience and diligence. Check each step methodically before completing this phase.

When interviewing candidates I ask "Where do most bugs come from?" By far the most common response is "Lack of attention to detail". Most people are aware of this, it takes self discipline to carry out the plan and check each step.


4.  Review and Discuss the Solution


Don't stop when you have the solution, there is one more important phase: Reviewing and discussing the solution. This is more than establishing the solution is correct, this is feeding the knowledge back into your minds idea making machinery. Gain a deep appreciation of what the new knowledge is and thinking of ways it can be applied in other contexts.

  • Can you check the results?
  • Can you check the logic?
  • Can you derive the result differently?
  • Can you see it at a glance?
  • Can you use the result or method for some other problem?
  • Make new connections





  • Test by dimension.
  • Use all relevant data.
  • Variation of the data.
  • Symmetry
  • Analogy
  • Make a concrete interpretation



Exercise


Let's put these recommendations to the test with an exercise. Please pay close attention to the process we take to arriving at a solution. The problem is: "Find the diagonal of a three-dimensional rectangle of which the length, the width, and the height are known".

In this room, if you know the dimensions, can you calculate the diagonal from one corner here to there?

First we have to understanding the problem:

  • What is the unknown?
  • What are the data?
  • Draw a diagram. Introduce suitable notation.
  • What shall we denote the unknown as?
  • What shall we denote length, width, height?
  • What is the condition linking a, b, c, x?
  • Is it a reasonable problem? Is the condition sufficient to determine the unknown?


Now let's devise a plan:

  • Do you know a related problem?
  • Look at the unknown! Do you know a problem having the same unknown?
  • Well what is the unknown?
  • Do you know a problem with a similar unknown?
  • A problem whose unknown is the length of a line?
  • The length of a diagonal?
  • Find a side of a right triangle.
  • Good! Here is a related problem. Can you use it?
  • Could you introduce some auxiliary element in order to use it?
  • The problem you remembered was about triangles, are there any triangles in your figure?
  • Could you find the diagonal if it were the side of a triangle?






It was a good idea to draw that triangle, how do you calculate the unknown?
Does everyone see that?
O.K. I see you have a plan.

Let's carry out the plan:

Introduce suitable notation for the intermediate leg
x2 = y2 + c2
y2 = a2 + b2
x2 = a2 + b2 + c2
x = root (a+b+c)

Check each step carefully!

Now it is time to looking back and review the solution:

  • Can you check the result?
  • Is the expression symmetric?
  • If the height decreases, and vanishes what happens?
  • If the height increases, the diagonal increases. Does your formula show this?
  • If the shape expands in the same proportions, does the diagonal also increase in proportion?
  • Does it matter if you use feet or meters?
  • Can you use the method for some other problem?
  • Say we put a flag on the roof of a building with cables holding it in place from each corner, how long are the cables?

OK great. The questions Polya recommends are not problem specific, and the methodology works.  Let's talk about software development.


In the context of SCRUM:



You will have already noticed many similarities with generic problem solving and software development iterations. The big difference is that typically these stages are split up among different team members. This yields some efficiency, but taken to the extreme can limit the benefits you accumulate from being involved in the complete set of problem solving phases. You want to be involved at some level in each phase to be able to grow your network of idea connections. When dividing up work it is in your best interests, and your teams, to avoid completely isolating yourself to one phase of the process. At the same time you do want to take advantage of the fact that certain team members are specialized.

Being an ace problem solver is a valuable skill. Translating those problem solving skills to a team environment is crucial to ongoing success.


Review your story with the Product Owner and the Quality Assurance Specialist to make sure everyone has the same understanding. Ask about and gain an understanding of the context of the story. Think through and plan your implementation before you start it. Discuss code changes with your team. Check your work methodically before declaring it ready for testing. Write unit tests to make sure you covered all the details.

Recognize that code complete is not done, there is more work required to complete a story, and it requires time. Discuss with QA what effect the implementation may have on the software. Follow up with your coworkers to make sure that your story goes through all phases of the cycle.

For defects, fill out the resolution field. You can often find bugs just by describing what you did because it forces you to review your solution. You are sometimes reminded of cases that you forgot to check. The additional explanation yields far better release notes for our customers.

Do a quick self code review of your changeset. Some changes turn out to be unnecessary and wrong after you find the real problem.

If the last thing you tested works, don't stop immediately, you may overlook the other aspects of the problem.

Recognize that team members have differing responsibilities but that you are all collaborating to solve real world problems and provide value to your customers. Each phase and each iteration must be cohesive to succeed.


Conclusion


Problem solving is a valuable and rewarding skill which can be cultivated. Use your software development process to augment your problem solving capabilities rather than stymie them. Find ways to use successful problem solving strategies in ways that work for your team.


References


How to solve it - George Polya
http://seattle.bibliocommons.com/item/show/2265464030_how_to_solve_it

Where good ideas come from - Steven Johnson
http://seattle.bibliocommons.com/item/show/2669592030_where_good_ideas_come_from

Hammock driven development - Rich Hickey
http://www.youtube.com/watch?v=f84n5oFoZBc

The Scrum Guide - Ken Schwaber, Jeff Sutherland
http://www.scrum.org/Scrum-Guides