A classic text on problem-solving by Jerry Weinberg. The book is short, but packed with wisdom. Especially useful if you are a software developer trying to build yet another feature for your application.
A problem is a difference between things as desired and things as perceived.
The fledgling problem solver invariably rushes in with solutions before taking time to define the problem being solved. Even experienced solvers, when subjected to social pressure, yield to this demand for haste. When they do, many solutions are found, but not necessarily to the problem at hand.
Without some common understanding of the problem, a solution will almost invariably be to the wrong problem. Usually, it will be the problem of the person who talks loudest, or most effectively.
Early during your problem solving phase, ask yourself:
- Who has a problem?
- What is the essence of the problem?
Since any problem is a difference between a perceived state and a desired state, when we change a state to “solve” a problem, we usually create one or more other problems. Put simply, each solution is the source of the next problem.
We never get rid of problems. Problems, solutions, and new problems weave an endless chain. The best we can hope for is that the problems we substitute are less troublesome than the ones we “solve”.
When something goes wrong in the software, we’re inclined to blame the user, rather than the person who made the software. Human beings are so adaptable, they’ll put up with almost any sort of bugs - until it comes to their consciousness that it doesn’t have to be that way. Then comes trouble.
Accompany a foreign traveler through your own country, for through the foreigner’s eyes you will once again perceive the strangeness and awkwardness of your own culture. Take some object (piece of code) that you handle ever day. See it from the point of view of someone from another country who has never seen one before. Each new point of view will produce new issue to be addressed with the solution.
Don’t solve other people’s problems when they can solve them perfectly well themselves.
Many problems in our society stem from systems designers and decision makers who don’t experience the problems they’re “responsible” for.
Try blaming yourself for a change. Think about the problem as being “my” problem, rather than somebody else’s problem.
Where problems come from?
The source of a problem often contains some key element in its resolution.
Most people with problems think they know what these problems are. They are usually wrong. Most people also think that they are not very good problem solvers. However, many times solving a problem is rather easy - once we know what the problem is.
Most of us have had schooling - too much of it. We’ve developed an instinct that makes us seize upon the first statement that looks like a problem. Then we solve it as fast as we can, because exams focus on speed.
In spite of appearances, people rarely know what they want until you give them what they ask for.
Not too many people, in the final example, really want their problem solved, e.g. the treasurer who kept finding fault in the computer program because his salary was dependent on the job that the computer was trying to replace.
A question that every would-be problem solver should ask before seriously embarking on any problem: Do I really want a solution? Though the question seems shocking, sometimes the “solution” isn’t at all welcome, because it may put the solver out of a job.
We never have enough time to do it right, but we always have enough time to do it over. OR,
We never have enough time to consider whether we want it, but we always have enough time to regret it.
While solving problems, we often tend to regard “side effects” as the result of particular solutions. “They might not arise at all, and if they do, we can always refine the solution to eliminate them.” How often does this naive attitude lead us into disaster?
The fish is always the last to see the water.
When we contemplate problems, items to which we are habituated tend to be omitted from consideration. Only when the solution causes the removal of the habituated element do we become startled. The problem solver must strive to see the “water” in which the other participants unconsciously swim - the water which will be transformed to sand when the problem is “solved”.