Questions are so important when fault-finding; the more data you have, the more visibility you have of the situation.<\/p>\n
If you know what<\/b> failed, where<\/b> it failed, and\/or when<\/b> it failed then extraneous data can be discarded if it doesn’t match the answers to these questions.<\/p>\n
Would you really want to discard data? Surely the more data you have the better? Well, yes, to a point. But the objective is to find the fault; anything else is noise and may distract from the objective.<\/p>\n
This is the answer you really want; you might know the what<\/b>, the where<\/b>, and the when<\/b>, but until you can explain why<\/b> you cannot fix the problem. Fault finding is about taking the what<\/b>, where<\/b>, and when<\/b>, and coming up with the why<\/b>.<\/p>\nHow<\/h3>\n
How<\/b> you fix the issue is up to you; if you know why a system doesn’t work then you have many options of how to deal with that problem. It might involve replacement, repair, or just plain ignoring the issue if it isn’t worth addressing.<\/p>\n","protected":false},"excerpt":{"rendered":"
Questions are so important when fault-finding; the more data you have, the more visibility you have of the situation. What, Where, When If you know what failed, where it failed, and\/or when it failed then extraneous data can be discarded if it doesn’t match the answers to these questions. Would you really want to discard … <\/p>\n