September 24, 2012

Philosophy 18

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

Saying something does work when it doesn’t

Saying something doesn’t work when it does

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

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″.

Related

I’d say the worst offence is the issue you finish with Jonathan – to simply pass judgement on a feature you have not actually tested for yourself. Sadly there are a lot of articles out in the web sphere where people simply repeat a claim or statement without checking into it. Or, worse still, pass on a garbled version from an incorrect opinion they have gained without understanding what has already been said.

As you say, if we actually test (or at least research) what we put forward as facts (“this feature does/does not work in respect of X”) then we reduce the chance of error. We should state version, our assumptions, assumed knowledge and the details of what we observed – but that can lead to very dry and complex posts, which read more like scientific papers and how much fun are they to digest. I struggle more with that balance than most anything else in communicating technical information.

Sometime it is just an opinion being stated. I’ve said a few things myself based only on theory – but I like to believe I make that obvious. I feel doing so is important and is part of stating your assumptions. The assumption is, I am saying this but could well be wrong…

Of course, anyone relying on feedback from the web on whether or not to use a feature that is important to them should do more than take one opinion – even yours :-)

Actually, getting it wrong (one way or the other) or even not test are not the worst offences in my opinion. It’s refusing to accept that you got it wrong when evidence is given and not gracefully retracting your opinion. Thus knowingly misleading people. That really ticks me off.

To be scientific, you have to use a fairly passive descriptive voice, clearly delineating all experimental parameters. To sell yourself to the general population, you have to create a sense in the readership of knowing what is going on. The intended audience must be the context for judging good or bad. If you have a mixed audience, there is no general answer. One possible answer is to do it the best you know how, ignore haters, and listen to constructive feedback, which of course is how the best publishing works.

That said, using replicable demos mostly moots the problem. If you are wrong, the whole world can see it. Scary, but if you have a dynamic system that encourages feedback and intelligent discourse, everyone can benefit. That’s hard to do with any system that has deadlines and static output, in scientific publishing that is worked around by peer review and references, with predictable issues of cabals and cliques. If you have a dynamic system that lacks proper feedback, well, that would be the forums.

I always thought it was lame when anyone would trumpet a feature that doesn’t work. Bugs count in real life. Results count in real life. Yes, I’m still irritated by that MTS class I took in the ’90s.

For strategic direction, you have to trust that Oracle marketing is somewhat on the level. There’s no way to verify that trust, and really, any feature or product may be decremented. Even non-Oracle products superior to Oracle products can be bought by Oracle and killed (or assimilated, depending on your viewpoint).

People get emotionally invested in their own words. It can be tough to both criticize and leave a graceful way out. Especially if someone is so wrong it seems counterproductive to leave a way out. Once it becomes a debate, then there must be losers.

I agree with both comments above. Martin touches on the most important aspect of publishing opinions (proofs or theorums) , everyone makes mistakes. Whether they are published or not is irrelevent. What is important is that if you find your theory was wrong, accepting it is wrong and moving forward from that point is the correct philosphy.

I am reminded about a scientific presentation I was told about where a scientist, I think he was an astronomer, had worked for 30 years on a particular theory and was convinced of it’s validity. He attended a presentation by another scientist who in the course of about two hours totally destroyed the first scientist’s life work. After the presentation, the first scientist went up to the presenter and thanked him for pointing out the errors in his work.

That to me that example is what scientific philosophy is all about. Working to prove an opinion, accepting you may be wrong, changing your opinion if you are wrong.

I think when working in Oracle database field, all I can do is come close to the Truth as much as possible. The Truth, of course, being exactly how things work – which is something that only the developers and architects of the feature know for sure. After all, it’s just arbitrary – however they decided to design. And no one from that group is revealing the Truth short of exposing the “trade secrets”. And taking into consideration the nature of internet (i.e. not everything that is printed on the webpage is the truth), you do your best to get as close to the Truth as possible, and the time you find you are not close enough, you get that much closer. Somewhat philosophical, but then again the title is just that. When documentation isn’t enough and google search isn’t enough, expert blogs aren’t enough and my own testing isn’t enough what am I supposed to do? And when do you know it’s not enough? And then there are always bugs that will throw all my planning overboard in an instant. And none of this is changing any time soon.
So I don’t look at it as the ‘worst offense’. We try to do best we know how provided the circumstances. After all, I am not a computer; I am a human being.

“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”
or indeed the opposite, which classify as orders of magnitude worse: considering an idea as a strategic direction on the basis of a single article.
Often times thoroughly out of context to its applicability or even suitability for the case on hand.
Incredibly common nowadays, where quoting an article from wikipedia – or any other random site – is considered the pinnacle of research…