Written by Bjørn Børresen
on 

Cutting the Gordian Knot

“Gordius, the King of Phrygia, once tied a knot that no one could untie. It was said that he who solved the riddle of the Gordian Knot would rule all of Asia. So along comes Alexander the Great, who chops the knot to bits with his sword. Just a little different interpretation of the requirements, that’s all… and he did end up ruling most of Asia.”

So begins chapter seven of one of my favourite programming books of all time.

Finding the answers to impossible problems is all about asking the right questions. So, here you have them ;-)

Problem solving questions

TPP promises; “Many times a surprising revelation will come to you as you try to answer one of these questions.”

One of the original books on heuristics in problem-solving was G. Polya’s “How to Solve It” (1957). Although his book is about problem solving in mathematics, it can just as well be used for software engineering.

Here’s a summary of Polya’s problem solving approach:

  1. Understanding the problem. You have to understand the problem. What is the unknown? What are the data? What is the condition? Is it possible to satisy the condition? Is the condition sufficient to determine the unknown? Or is it insufficient? Or redundant? Or contradictory? Draw a figure. Introduce suitable notation. Separate the various parts of the condition. Can you write them down?
  2. Devising a Plan. Find the connection between the data and the unknown. You might be obliged to consider auxiliary problems if you can’t find and intermediate connection. You should eventually come up with a plan of the solution.     Have you seen the problem before? Or have you seen the same problem in a slightly different form? Do you know a related problem? Do you know a theorem that could be useful?     Look at the unknown! And try to think of a familiar problem having the same or a similar unkown. Here is a problem related to yours and solved before. Can you use it? Can you use its result? Can you use its method? Should you introduce some auxiliary element in order to make its use possible?     Can you restate the problem? Can you restate it still differently? Go back to definitions.   If you cannot solve the proposed problem, try to solve some related problem first. Can you imagine a more accessible related problem? A more general problem? A more special problem? An analogous problem? Can you solve a part of the problem? Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary? Can you derive something useful from the data? Can you think of other data appropriate for determining the unknown? Can you change the unknown or the data, or both if necessary, so that the new unknown and the new data are nearer to each other?     Did you use all the data? Did you use the whole condition? Have you taking into account all the essential notions involved in the problem?
  3. Carrying out the Plan. Carry out your plan. Carrying out your plan of the solution, check each step. Can you see clearly that the step is correct? Can you prove that it’s correct?
  4. Looking back. Examine the solution. Can you check the result? Can you check the argument? Can you derive the result differently? Can you see it at a glance?     Can you use the result, or the method, for some other problem?

Woh! That’s a lot of problem-solving questions for you – it’s almost like finding the “unsub” in an episode of the CBS show Criminal Minds isn’t it?

Also, notice how similar this is to design patterns? Those problem solving questions are almost like a design pattern for finding solutions! Go ahead – print them out, and refer to them when needed.

Comments

Comment by Bjørn Børresen on 2009-11-06 19:52:13 +0000

Another question:

:-)