Trust

Here’s a guideline on how much trust to place in advice you get from articles about Oracle published on the Internet (even the ones published by Oracle Corp.):

• 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
• For ‘technical implementation’ details, if the feature set described does not match 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
• If there’s a rational justification and repeatable test case but the feature set doesn’t match the one you’re using – 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.

Update 19th Aug 2010

Since this note was more than 18 months old it needed to be validated (according to its own standards) – and there were  a couple  more thoughts that crossed my mind:

• If the only justification for a claim is an extract from the Oracle documentation then check that the quoted article (still) exists – and if it doesn’t exist or the quotation isn’t accurate don’t trust the claim.
• If the only justification supplied in an article is an extract from the Oracle documentation don’t quote the article to someone else, supply the link (or reference) to the original documentation – it’s more likely to be in context, and it’s more likely to be corrected and brought up to date (eventually) if it’s wrong.

Update (20th Jan 2013)

Time passes so quickly – I should have reviewed and re-affirmed this item months ago. On the other hand, I’ve just decided it’s not really about Oracle (exclusively) and it’s definitely not a detail of technical implementatin, so it doesn’t really apply to itself. It’s going be valid for years.

Update (19th August 2015)

I just failed to follow my own guidelines – see posting referenced by the last pingback below – so I decided to remind myself of the comments I made all those years ago. And then had to insert one more caveat to the list.

Update (1st Nov 2019)

Too much time has passed since I last checked and okayed this post. In the interim one more thought has occured to me:

• Even when all the details of the thing you’re reading are perfect and there is a repeatable test case – and even after the repeatable test case produces the same results in your environment, and after you’ve decided you can’t come up with an alternative explanation to the one supplied: look carefully at all the side effects and activity that took place in case there’s something there that didn’t matter to the original poster but might matter to you.