## How to Solve It!

In *How to Solve It*, **George PĆ³lya** describes a method of solving mathematical problems which I think can help users, analysts and developers in their work.

**George Pólya** was a mathematician born in Budapest in 1887. In 1945 he wrote *How to Solve It* ( | ), a classic introduction to mathematical problem solving. In it, he describes a simple process which is applicable to all kinds of problem solving, not just mathematics.

Writing software is a process of continuously solving problems at many levels of abstraction. Users need to understand what they want, analysts need to figure out the details of the user’s needs, and developers need to understand both the user and the analyst, and solve the problems (and contradictions) they present.

Its often very difficult for people who do not spend every minute of their working day solving problems, to tackle the problems presented to them by complex software development. It takes years of *active and reflective* practice to develop those skills.

I think Pólya’s work could help to start users, analysts and developers off on the right track.

## Pólya’s Method

### First: Understand the Problem

- What is the unknown?
- What are the data?
- What is the condition?

### Second: Devising a Plan

- Have you seen the problem before?
- Have you seen the problem in a slightly different form?
- Do you know a related problem?
- Here is a problem related to yours and solved before? Could you use it?
- Could you restate the problem?
- If you cannot solve the proposed problem try to solve first some related problem.
- Could you imagine a more accessible related problem? A more general problem? A more special problem?
- Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary?
- Could you derive something useful from the data?
- Could you think of other data appropriate to determine the unknown?
- Could you change the unknown of 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 taken into account all essential notions involved in the problem?

### Third: Carrying Out the Plan of Your Solution

- Check each step.
- Can you see clearly that the step is correct?
- Can you prove that it is correct?

### Fourth: Looking Back

- Examine the solution obtained.
- Can you check the result?
- Can you check the argument?
- Can you derive it differently?
- Can you see it at a glance?
- Can you use the result, or the method, for some other problem?

## Pólya’s Method in Software Development

Its obvious that Pólya’s Method can be used in the process of writing software itself, but how can users and analysts use it?

I would like to suggest the following…

### First: Understand the Problem

- Obvious, but obtaining a clear statement of the problem is a vital step often missed as stake-holders make assumptions about the motives and understanding of others.

### Second: Devising a Plan

- Have you seen the problem or something similar before?
- Is there a problem related to yours and solved before? Could you use it?
- Could you imagine a more accessible related problem?
- Could you derive something useful from the related information?
- Did you use all the related information?
- Have you taken into account all essential notions involved in the problem?

### Third: Carrying Out the Plan of Your Solution

This is the job of the software developers, carrying out the solution is done by writing tests and making them pass.

### Fourth: Looking Back

This is critical, how can anything be learnt without reflection? In software the steps above can be carried out after devlopment has completed their work:

- Can you check the result? Yes, through unit and functional tests. Do all the other tests still pass? Is the system still useable and make sense?
- Can you derive it differently? Refactor the code, rework the workflow, the UI, etc
- Can you see it at a glance? When using the system does it feel right?
- Can you use the result, or the method, for some other problem? The holy grail of software development: Reuse!

Finally, Pólya had the following to say in *How to Solve It*, which has relevance to the software practitioner:

The first rule of discovery is to have brains and good luck. The second rule of discovery is to sit tight and wait till you get a bright idea.