Continued from page 1
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
problem is same as an earlier problem. I manage a number of computer systems. One of 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 report, which had happened before. Thus I put incorrect priority on issue and didn't look at it until afternoon. When I looked, I discovered to my horror that ALL faxes had failed (which caused 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 evidence that exists.
Rule #13: Don't trust 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 way world is, so don't beat your head over it. Read any documents you can get your hands on, but also look at code and anything else pertinent.
Rule #14: Don't assume it ever worked. Many years ago, I had 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 code to new machine and tried to run it. Several errors occurred (squares not square and triangles not triangular), and these did not occur on 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 middle of being modified, and programmer who was doing modifications quit and didn't tell anyone. Thus, code we were using never worked, and thus, well, we didn't do anything wrong. Once we had 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 result of incompetence - 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.
Richard Lowe Jr. is the webmaster of Internet Tips And Secrets at http://www.internet-tips.net - Visit our website any time to read over 1,000 complete FREE articles about how to improve your internet profits, enjoyment and knowledge.
