Philosophy 18

Philosophy 18:
A question I asked myself recently was this:

Which is the worst offence when publishing an article about some feature of Oracle:

1. 
   
   
   Saying something does work when it doesn’t
   
   


2. 
   
   
   Saying something doesn’t work when it does
   
   


3. 
   
   
   Saying something does work when in some cases it doesn’t.
   
   


4. 
   
   
   Saying something doesn’t work when in some cases it does.
   
   

I don’t think it’s an easy question to answer and, of course, it’s not made any easier when you start to consider the number of cases for which a feature does or doesn’t work (how many cases is “some cases”), and the frequency with which different cases are likely to appear.
I’m not sure that there is a correct answer to the question, but in terms of impact (time wasted) I’m inclined towards damning claims that something works when it doesn’t – imagine the two extreme scenarios:

• Someone is trying to solve a problem and finds a publication that offers a solution that is supposed to work – how much time might they waste attempting to make that solution work because they “know” it should work.


• Someone comes across a publication that says a mechanism they’ve already implemented successfully doesn’t work (they won’t be searching for the article, of course, because they’ve already solved the problem). They’re not going to waste any time – unless they decide to point out the error in the article.

There is, inevitably, a counter-argument. Someone may be looking for strategic ideas on how to approach a major stage in their implementation, and discard a very useful line of attack because of a publication that says it won’t work. If that happened the consequences could have a major impact on the quality and scalability of the end product; but I’d like to think that anyone thinking strategically about design options wouldn’t be inclined to discount an idea on the basis of a single article unless it contained some very good arguments and demonstrations.
Perhaps the issue is not so much what an article says, but how it says it. It’s okay to be wrong or (as happens more frequently) partially wrong provided you have some clear demonstration of the work that you did to come to your conclusion. If you’ve provided some evidence (and managed to present it cleanly) it gives the readers the opportunity to make observations like: “the example is storing integers in a varchar2() column”, “the example uses a two-column index, but I will have a single column”, “the example is using smallfile tablespaces, not bigfile” and, perhaps most significantly, “the example is running on 8.1.7.4, not 11.2.0.3″.



DIGITAL JUICE