Read the Problem First

A bad solution is often a flawless answer to a misread problem.

Before any calculation or action it is worth establishing:

• what is known;
• what has to be found;
• which data are missing;
• which constraints apply;
• whether the problem is stated unambiguously;
• what we added ourselves that was not in the statement.

It helps to restate the problem in your own words. If the restatement will not come, there is nothing to solve yet.

A drawing, a diagram or a table often replaces a page of reasoning. Not because pictures are for people who find reading hard, but because different forms of representation reveal different properties of the problem.

A diagram is especially good at exposing hidden assumptions. In words, two events can look connected. On a timeline it turns out that the supposed cause happened after the effect. In a long description all the participants look equally important. On a diagram it is clear that one of them has no connection to the process at all and probably ended up on the email by accident.

A well-stated question does not contain a ready answer, but it sharply reduces the space of meaningless ones. Sometimes that is most of the work.

Half the work of technical support consists of reconstructing the problem statement. A user writes: “email isn’t working”. Ten minutes later it turns out that mail is going out but one particular recipient is not getting it, and not all of it, only messages with attachments, and only since last week, when the company changed its antivirus. The original wording was not a lie. It was compression: the person reported a conclusion rather than an observation, and compressed exactly the part that contained the problem.

So the first useful question is usually not “what broke” but “what did you do and what did you see”. The answer to that contains the problem statement. The answer to the first contains somebody’s version of the solution, adopted before the investigation began.