SILLY SEELEY

Have you heard the one about the development lab manager who would come every morning to work and say to his programmers “Let’s code this sucker fast, so that we have enough time to debug”? An old joke, which, like so many other good ones, is not entirely devoid of anchoring in reality.

Following Objective Objectivity? Reply to Guzenda, an exchange in the DM-DISCUSS forum was recently brought to my attention. It was initiated by one Dwight W. Seeley, who states as follows:

“Just finished reading F. Pascal’s latest. I have no doubt that Mr. Pascal is a very intelligent person, but his latest, in TDAN, is nothing more than what he claims was being leveled against him. This is just writing for writing’s sake. Nothing of any substance here, except that Mr. Pascal has used his forum to vent a frustration that is obvious to many.

I just have one request of Mr. Pascal. Stop writing and do something! If all of his statements are true and his various premises valid, then at some point critique should stop and action prove his positions. If one does not like the state of things, indeed, one should express their opinions. But after years of expressing that opinion, one should be able to correct the many problems that Mr. Pascal sees.

Mr. Pascal’s bio suggests that he has consulted with many DBMS vendors. What critique or suggestions have they taken? Will anything ever satisfy Mr. Pascal? Perhaps an implementation of his ideas? So why hasn’t he done this? Or is Mr. Pascal just an example of the stereotypical, “them that can, do; them that can’t, critique (constantly)”.

After awhile [sic], the “things shouldn’t be this way, but should be this way” critique wears thin. Mr. Pascal, if no one will take your advice and do what “should” be done, why don’t you create the solution that exemplifies all of the issues? Criticism is easy. Doing something about it, takes passion and the belief that one is, indeed, correct.”

I wish I could be as sure of Seeley’s intelligence as he is of mine, but he does not make it very easy. My instinctive reaction was: yet another variation on DBMWTIHPTTD (short for “Don’t bother me With theory, I have practical things to do”), so typical of the IT industry. If my critique “has worn thin”, why doesn’t he simply ignore it? After all, the titles of my last book, and my web site make it clear that my writings are (a) intentionally critical and (b) intended for the thinking practitioner. And I am fairly sure Seeley is not a thinker!

The obvious conflict of interest with which the trade media is riddled, and whose deleterious consequences I have been amply documenting, are hardly as inconsequential as just “my frustration”. My TDAN column to which Seeley reacted demonstrates a most blatant such consequence: a web publication invites a vendor—a current or potential advertiser/sponsor—to counter scientifically grounded, technical criticism with marketing baloney, refuses to publish a rebuttal that exposes the latter, and ultimately terminates the column for lack of a sponsor!! Kind of mind-boggling, a problem bad enough that even Seeley should be able to appreciate. But he does not, and fails even to realize that the problem actually defeats his very main point!

Consider his argument: instead of criticizing, I should “create a solution that exemplifies all of the issues” I have been raising. But if my criticism of how the industry (practitioners, vendors and the press) operates is accurate, what guarantee is there that such a solution will be received any better than my arguments over the years?

Well, I can hear Seeley say, a product will “speak for itself”. But that is, of course, an illusion. Appreciation of a correct solution—essentially, a well-implemented, truly relational DBMS (TRDBMS)—

depends on knowledge and understanding of data fundamentals, of which there is preciously little in the industry. After all, even the “efficient market” dogma (to which undoubtedly Seeley subscribes, and which informs his belief that best solutions always prevail on merit) is predicated on well-informedsellers and buyers. How and why would vendors implement the right solution, if neither they, nor practitioners know and understand what it is? The whole point of my criticism that so annoys Seeley, is that neither vendors, nor users (who are too busy “doing”, to do any thinking), can even acquire knowledge, because the industry and media not only do not reward it, but often punish it; and that is it is practically impossible even to acquire a proper education these days (see my first and second editorials.)

In fact, Seeley himself lacks such knowledge, which is why he must resort to trivializing my critique as just pique, instead of addressing its substance:

· Everything is just a matter of opinion to him. He cannot distinguish between marketing hype and soundly grounded technical arguments; for Seeley it is not the former by Guzenda that is devoid of any substance, but the latter by me;

· “If my statements are true and my various premises valid, then…”, he says. He cannot judge this for himself. If he could, he would know that those statements and premises do not originate with me, logic is thousands of years old

How can “things be corrected” if practitioners are incapable of making this kind of judgment? Most practitioners prefer to operate in what I often refer to as a “cookbook mode”: they are not interested in understanding, but rather prefer “tricks and trips”, “recipes” of sorts that they can replicate without much mental effort. Anything that is not product- and project-specific is “theory” and, therefore, not practical. Thinking is an unproductive waste of time, you gotta “do” something to count. There are more than enough database “mechanics”, but very few thinkers (and Seeley wants even them to stop writing).

Note: Interestingly, I recently had an exchange with a vendor who does try to implement some TRDBMS features, but has a hard time with uneducated, uninformed practitioners.

G. Michael Zimmer responded to Seeley’s comments as follows:

“Well, often Fabian Pascal's views come across (to me) as pedantry, but there does seem to be substance regardless.

It is interesting that Fabian Pascal has been dropping hints for month that something better is in the offing, true relational database management systems. I quote from the article: "the solution are TRDBMSs which, as I have alluded in other writings, are now feasible thanks to a newly invented implementation technology".

Still no details on the technology as far as I can see; isn't there a term for this in the IT business? Still, even if the promised TRDBMS technology is delivered soon, proves practical, and it is quickly ready for prime time, it is not clear what sort of adoption curve there will be. Someone, perhaps Moore in Inside the Tornado: Marketing Strategies from Silicon Valley's Cutting Edge, made the claim that a technology had to be 10x better in order to displace an entrenched technology. I'm not sure that I believe that, since there are obviously other factors, but there is a case to be made that something like this (10x) applies, for all kinds of practical reasons.”

If by pedantry Zimmer means my insistence on precision and clarity, then I plead guilty as charged. Fuzziness and confusion are major problems in database management—a field founded on logic!—which relational technology was intended to eliminate. If they are permitted, anything can be claimed, even contradictions.

Regarding the new technology I have been alluding to—the TransRelational Model—unfortunately I am not at liberty to say much about it beyond what is already posted on this site. What I can say is that:

· It is not a TRDBMS, but an implementation technology, that is, it can be used to implement TRDBMSs (as well as other types of software);

· By TRDBMSs I mean DBMSs which, unlike those based on SQL, do not have to rely on a fixed physical order of rows and columns, which inhibits optimization. By doing away with the need for such reliance, a TRDBMSs tables become true sets and, thus, can take full advantage of the relational benefits, not the least of which is a way much richer optimization repertoire, which SQL implementations cannot even dream of.

I advise practitioners to focus less on cookbooks and industry hype (with which Seeley seems content), and more on proper foundation knowledge, which is a pre-requisite for the availability of sound products, and without which the industry wall go backwards, like it now does with XML. Alas, this requires thinking (and ability thereof).

Posted 9/12/03