Beware of Question Authorities

Following suggestions are from Mr.Lewis Blog ;

* If it’s not dated – don’t assume it’s true
* If its date is more than about 18 months old – don’t assume it’s (still) true
* If there’s no version number – don’t assume it’s true
* If it’s not your exact version number – don’t assume it’s (still) true
* For ‘technical implementation’ details, if there’s no platform mentioned – don’t assume it’s true
* For ‘technical implementation’ details, if the platform’s not the same as yours – don’t assume it’s true
* If there’s no rational justification supplied, and no repeatable test case – don’t assume it’s true.

And even when all the details are perfect and there is a repeatable test case – and even after the repeatable test case produces the same results – ask yourself this question:

“Could there be a different explanation for the same set of results – and if so, how badly could this advice damage my system, and how hard would it be to test my alternative hypothesis ?”

Once you’ve got through that lot – then you might be safe trying the advice on a development system.

Mr.Kyte also mentions this problem under the ‘Question Authority.’ terminology;

There are lots of ‘experts’ out there;
* Make them prove everything
* Statements that should raise your eyebrows:
It is my opinion…
I claim…
I think…
I feel…
* Everything can (and should) be proven
TKPROF goes a long way here
Statspack is great
‘Runstats’ is a tool I use as well (search asktom for runstats)
* Things change, expect that

Remember a test becomes a proof when;

– it has a specification
– the results are reproducible
– alternative explanations have been eliminated
– it is published
– it survives peer-group review

Reference
“The Burden of Proof” presentation by Jonathan Lewis

Don’t take any “guru’s” word, test it and make sure you are convinced of the results..

3 Comments