<< Chapter < Page Chapter >> Page >

"so then i tried ..."

If you're just starting out, or even if you're a seasoned professional, why did you violate the first fundamental rule of troubleshooting: Stop, Drop, and Roll ?

If you've violated that first rule, you may very well be exacerbating the problem rather than ameliorating it. There are a lot of things you might do when an error or bug comes up. Many of them make the problem worse. For example, maybe you've deleted all your Word documents by mistake, but before calling in any expert help, you tried reinstalling Word, and then running a disk defrag. Neither of those will help recover the deleted files, and between them they will probably scramble the disk to the extent that no Undelete program in the world will been able to recover anything. There might be a chance if the system is left alone.

Users like this are like a mongoose backed into a corner: with its back to the wall and seeing certain death staring it in the face, it attacks frantically, because doing something has to be better than doing nothing. This is not well adapted to the type of problems computers produce. Instead of being a mongoose, be an antelope. When an antelope is confronted with something unexpected or frightening, it freezes. It stays absolutely still and tries not to attract any attention, while it stops and thinks and works out the best thing to do. (If antelopes had a technical support line, it would be telephoning it at this point.) Then, once it has decided what the safest thing to do is, it does it.

When something goes wrong, follow the first law of troubleshooting! Immediately stop doing anything. Don't touch any buttons at all. Look at the screen and notice everything out of the ordinary, and remember it or write it down. Then perhaps start cautiously pressing "OK" or "Cancel", whichever seems safest. Try to develop a reflex reaction - if a computer does anything unexpected, freeze. If you manage to get out of the problem, whether by closing down the affected program or by rebooting the computer, a good thing to do is to try to make it happen again. Programmers like problems that they can reproduce more than once. Happy programmers fix bugs faster and more efficiently.

"i think the tachyon modulation must be wrongly polarised"

It isn't only non-programmers who produce bad bug reports. Some of the worst bug reports ever written come from programmers, and even from good programmers. Take the example of the programmer who kept finding bugs in his own code and trying to fix them. Every so often he'd hit a bug he couldn't solve, and he'd ask a colleague over to help. "What's gone wrong?" they ask. He replies by stating his current opinion of what needed to be fixed.

This worked fine if his current opinion was right - it meant he'd already done half the work and together the problem could be solved. It's efficient and useful. But quite often he was wrong. Work could go on for some time trying to figure out why some particular part of the program was producing incorrect data, and eventually the discovery is made that it wasn't, that the investigating was in a perfectly good piece of code, and that the actual problem was somewhere else. There's wasted time.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Debugging and supporting software systems. OpenStax CNX. Aug 29, 2011 Download for free at http://cnx.org/content/col11350/1.2
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Debugging and supporting software systems' conversation and receive update notifications?

Ask