I've been working in the world of computers for 23 years, and I've
learned a lot about problems during that time. I've found a few rules
which, if followed, make it easier to find, understand, correct and verify
problems.
- Rule #1: Don't assume you understand the problem.
- This is one of the classic mistakes of problem solving - you think
you understand what's going on, but you didn't look deep enough or get
enough information to really get it. Before starting to solve any
problem, be sure you spend some time and be absolutely sure you
understand exactly what's going in.
- Rule #2: Don't assume that the person who reported the problem
understands the problem either.
- In the computer field, I've found that users will report problems in
many different, often bizarre ways. Sometimes they will describe it in
such a manner that it appears to make sense, but actually what they are
describing has no relation to the problem at all. Remember, most people
do not understand computers and the related technology at all, so they
tend to piece together descriptions based upon what they have heard,
what they think they know and what people have told them.
- Rule #3: Duplicate the problem.
- Always, always, always duplicate any problem before you start
working on finding a solution. Why? See Rule #4. In addition, if you can
make a problem occur again, there is a much better change that you
really do understand what's going on (rule #1).
- Rule #4: You cannot know you have solved a problem unless you
followed Rule #3.
- The only way to be sure that a problem is solved is to fix it, then
exactly replicate what happened. The sequence is simple: duplicate the
problem, fix the problem, then try and duplicate it again. If you've
exactly replicated the issue, then you can be reasonably sure you've
fixed it.
- Rule #5: Don't assume someone else understands the problem.
- If you need to delegate the problem to another person, or if you are
receiving instructions from another person to solve the problem
yourself, do not ever assume they understand what they are talking
about. Always follow Rule #3 to be sure YOU understand the problem. Do
not take anyone else's word for it. If you delegate the problem, make
sure the person you give it to follows Rule #3.
- Rule #6: Don't assume you have just one problem.
- Sometimes things are more complicated than they seem. It's never a
good idea to assume that there is just one problem to be solved.
Throughout the entire problem solving process, keep your eyes open and
find any additional problems that you may see.
- Rule #7: Don't assume there is more than one problem.
- Also, don't make the assumption there is more than one problem
either. How do you follow rules #6 and #7? Just base your conclusions
upon what exists, not upon your assumptions or what others have told
you.
- Rule #8: Don't assume there is a problem at all.
- Just because someone reports a problem does not mean there is
actually a real problem. I remember when I got very upset because my car
was making a strange noise. I brought it to the mechanic and had him
spend hours checking my car to fix the noise. As it turned out, the
noise was normal and was not a problem. Hours wasted when there was no
problem at all. If the mechanic had followed Rules #2, #3 and #8, I
would have been out of the shop in a few minutes.
- Rule #9: Don't assume you don't have a problem either.
- Again, don't make assumptions. Base your conclusions upon what
exists, not what you assume to exist.
- Rule #10: Don't assume the problem is the same as an earlier
problem.
- I manage a number of computer systems. One of the functions of these
systems is to fax several thousand purchase orders to venders over
night. One day someone reported that they could not see any failures,
and it's unheard of for no faxes to fail. I assumed. mistakenly, that
this was a failure in the report, which had happened before. Thus I put
the incorrect priority on the issue and didn't look at it until the
afternoon. When I looked, I discovered to my horror that ALL faxes had
failed (which caused the failure list to fail also, as it made an
assumption that at least ONE fax would work). This caused incredible
grief which could have been avoided had I actually looked instead of
making an assumption.
- Rule #11: Don't assume it's a computer error.
- Not all problems are caused by machines. You could spend countless
hours trying to fix something that was actually a data entry error or
had some other human cause.
- Rule #12: Don't assume it's not a computer error.
- By now you should thoroughly understand this. Don't make
assumptions. Look and form your conclusions based upon the evidence that
exists.
- Rule #13: Don't trust the documentation.
- Use technical documentation as a resource, but do not assume it is
correct. Programmers are notorious for allowing their documentation to
slip into uselessness. That's just the way the world is, so don't beat
your head over it. Read any documents you can get your hands on, but
also look at the code and anything else pertinent.
- Rule #14: Don't assume it ever worked.
- Many years ago, I had the assignment to convert a plotting package
from one computer system to another. It appeared to be a simple project
(I violated Rule #15) so we just moved the code to the new machine and
tried to run it. Several errors occurred (squares not square and
triangles not triangular), and these did not occur on the original
machine. We spent months (literally!) trying to figure out what we did
wrong. As it turned out, we violated rule #14. The code was in the
middle of being modified, and the programmer who was doing the
modifications quit and didn't tell anyone. Thus, the code we were using
never worked, and thus, well, we didn't do anything wrong. Once we had
the proper code (from an old backup) it really was very simple.
- Rule #15: Don't assume it's simple or complex.
- Just remember it is what it is. Some problems are simple and some
are complex. Don't assume either until you have done your analysis.
- Rule #16: Don't assume maliciousness.
- If you find a human error, don't assume it was malicious. Generally,
human errors are the result of incompetence - the person did not
understand what he or she was doing. Start with training to correct
human errors - you can move to harsher methods later if training doesn't
work.
I hope these rules are of value to you in your problem solving
endeavors.
Unless otherwise noted, all photos and text is Copyright © Richard G Lowe, Jr.