Rules of Thumb: When Things Break
Rule of Thumb 37: No matter how bad it is, it can get worse. Sometimes spectacularly so.Debugging
Rule of Thumb 38: First, do no harm. Rule of Thumb 39: If you ask whether the machine is plugged in and turned on, it will turn out to have a subtle software problem. If you don?t ask, it will turn out not to be plugged in. Rule of Thumb 40: The first question is ?Is it plugged in?? The second question is ?At both ends?? Corollary 1: The third question is ?To an outlet that?s actually providing power?? Corollary 2: The mere fact that the device has power does not imply that it is in fact plugged in. Many devices have batteries. Rule of Thumb 41: A hardware person will always trace the error to software. A software person will trace the error to hardware. A user will trace it to whatever they dislike most ? usually either security or the network. Rule of Thumb 42: It?s human to blame problems on outside causes. By contrast, an outsider will always suspect the insider as the cause. Rule of Thumb 43: The right to avoid self-incrimination overrides the duty to tell the absolute truth for almost everybody. Rule of Thumb 44: Cockpit error is the most common cause of problems. Corollary 1: Everbody is a pilot. Corollary 2: There are many causes of cockpit error, and the pilot actually being stupid is not the most common. Rule of Thumb 45: At any given site for any given application or feature, there?s someone who knows more about it than the support staff. Finding that person is the first step to take to diagnose any given problem. Rule of Thumb 46: When you have eliminated the impossible, whatever remains, however improbable, must be the truth. Rule of Thumb 47: Pure logic is like a purple stretch velvet minidress: devestating in the right context, but not always appropriate. Corollary 1: Impure logic ? logic mixed with a great deal of empirical testing and pragmatism ? is the little black dress of debugging, appropriate for every situation with only minor changes of accessories and the proper attitude. Rule of Thumb 48: The person who says ?I didn?t change anything? isn?t always lying. Sometimes they?re just ignorant or forgetful. Rule of Thumb 49: No matter how many times the documentation or the user support line has been annoying and wrong, you will also be annoying and wrong if you do not check with them both at some point in the debugging process.Fixing Things
Rule of Thumb 50: Time to diagnose and time to fix are completely unrelated. Sometimes one approaches zero while the other approaches infinity. This is especially hard to deal with when the diagnostic person and the fix person are not the same. Corollary 1: The technical name for a problem that is easy to diagnose but extremely difficult to fix is ?unintended feature?. Rule of Thumb 51: When in doubt, shut it down, count to 10 very slowly, and start it back up again. Corollary 1: If that didn?t help, try shutting it down, leaving it down for an hour, and starting it back up again. Rule of Thumb 52: If you don?t know why you?ve done something, you?ve done the wrong thing. Corollary 1: If you don?t document why you?ve done something, somebody in the future is going to do the wrong thing. Rule of Thumb 53: All other things being equal, everybody?s favorite repair option is the most violent. Corollary 1: If people know that there are some problems that can be fixed by hitting a disk with a rubber mallet, they?ll pull out hammers for ?command not found. Rule of Thumb 54: There is no such thing as a one-time program or a temporary fix. If you do it the first way it occurs to you, in 6 months you are going to be saying defensively ?Well, I was in a hurry and it seemed like a good idea at the time.? Rule of Thumb 55: There is no such thing as a perfect program or a permanent fix. If you wait until you have figured out the best way to do it and are able to implement it correctly, in 6 months you will still be saying ?Well, I?ve almost gotten it written and when I?m done we?ll never need to worry about it again.? Corollary 1: If, by some miracle, you actually succeed in implementing the perfect solution, the problem will immediately change and it will no longer be appropriate. The more people who are reassuring of the importance and permanence of the problem, the more likely this is. Rule of Thumb 56: Festina lente: It will take twice as long to do it fast as it would to do it carefully. If it?s 2:00 am, it will take at least four times as long. Corollary 1: Do not type faster than you can think. It is exactly like driving faster than you can steer -- tempting, fun while it lasts, and likely to lead to devastating crashes. Rule of Thumb 57: Whatever common sense may lead you to believe, it is absolutely true that being firm, calm, and in control is just as important in training computers as it is in training horses.
on 2007-06-26 at 05:08