A question I asked myself recently was this:
Which is the worst offence when publishing an article about some feature of Oracle:
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:
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 220.127.116.11, not 18.104.22.168″.