Re: Just one more anecdote

On 2 Aug 2005 19:22:07 -0700, "dawn" <dawnwolthuis_at_gmail.com> wrote:

>Kenneth Downs wrote:
>> dawn wrote:
>>
>> > Kenneth Downs wrote:
>> >> dawn wrote:
>> >>
>> >> > I'm sure there are numerous factors playing into the fact that the
>> >> > system touted in this MS Word document

>> http://www.microsoft.com/resources/casestudies/ShowFile.asp?FileResourceID=1611
>> >> >
>> >> > has been discontinued and written off to the tune of $67 million in s/w
>> >> > development as seen at
>> >> > http://biz.yahoo.com/prnews/050721/clth018.html?.v=16

[snip]

>> > I don't know why it failed, but I have a hunch (and it definitely could
>> > be wrong) that the data model was a factor. Your hunch may be
>> > different and you may completely discount my hunch. I would love to be
>> > able to figure out an experiment that would shed light on this
>> > question.
>>
>> This weakened assertion, that the data model "could be a factor" suffers
>> from the same problem as the original stronger statement, it is floating
>> free of any context or perspective.
>
>Yup, I'll gran that. If I thought it was simply my personal response to
>a rorschach test, I wouldn't mention it, however. I suspect I am not
>the only person on the planet with experiences that would lead me to
>this conjecture (not conclusion and not the whole of the matter). All
>such folks might be wrong, but there might be something here that is
>worth looking into. Just a hunch, that's all.

     Or there might not be. You can hardly use it to support your views until you have confirmed that it was a factor. Starbucks coffee might have had more to do with it than the data model. (An equally valid speculation.)

>> Because it is true that any architectural element "could be a factor" in a
>> project's failure, and it is moreover true that any number of human factors
>> "could be a factor" in a project's failure, it is downright misleading to
>> pick one out and trumpet it as worthy of attention. I have suggested the
>> political motivation, and my "hunch" comes right out of the documents you
>> provided, what is the source of your hunch, and can you stick to the
>> materials provided?

     Quite.

[snip]

>> > You don't have to take it seriously, I do. I'm on a quest to determine
>> > whether my experience of TCO for non-SQL-DBMS tools being significantly
>> > lower than for SQL-DBMS's is a fluke or has some basis. It is so hard
>> > to figure out how to get emperical data (you can't even compare tps
>> > between SQL and non-SQL dbms tools as best I can tell) that I've been
>> > reading up on theory. I also keep an eye open for project failures, in
>> > an effort to more hints.
>>
>> Please name a project you were involved in that justifies your claim to have
>> lower TCO experience,
>
>I don't think it would be ethical for me to provide that. Even if I

     I do not think that it is ethical for you to NOT provide that. If you make claims, it is up to you to back them up. We are not asking for proprietary data.

     In the past, I designed and wrote a system for Eaton's (a department store in Canada) for their home decorating department. There is no need for me to give confidential data when I state that. I can even go into some detail about the system without giving it all away.

>did, my experiences are also simply anecdotal. You can go to
>comp.databases.pick and request more anecdotes, but they will sway no
>one, other than those who experienced them first hand. Among those,
>there is a variety of opinions on what makes for the productivity
>gains.

     So why should we bother with your statements? If all you do is state an opinion unsubstantiated, what differentiates it to the casual observer from an uninformed bias? TWIAVBP, and there are many things to look at, things that appear to have more bang for the buck than unsubstantiated statements.

>> perhaps you may want to do that even in another
>> thread under a suitable heading.
>
>The anecdotes that are in public, or related to public companies, such
>as this one, Oxford Health, and others, might be similar enough. As
>you can see, any given example, and even 100 such anedotes would
>persuade no one. But like the flowers in the springtime, I like to
>take note of such stories as they bloom, before they are gone. This one
>I opted to take note of in public.

     But where is the rigor? You can make all sorts of claims. So what! Unsupported claims are useless.

     If it was not the coffee, maybe it was the colour of the decor. Studies have shown that colour of surroundings does have an effect, and and and.

>> But you cannot list the project in question because there is no evidence the
>> data model had anything to do with it.
>
>I know of no projects where there is any documented evidence of a data
>model being a significant component in either the success or failure of
>the project. I can imagine a project where this is the case, however.

     Cool. I can imagine a world where dragons exist. What does that say about this world though? Not much.

     Look! Look! Elvis!

     Well, it could have been Elvis.

>If you have an idea of how to collect emperical data on this (for no to
>low dollars), please let me know.
>
>> > What I find interesting is that people who have not worked with both
>> > data models are so certain that the data model had nothing whatsoever
>> > to do with the project failure. I would like to have such certainty,
>> > but until then I'm stuck with hunches.
>>
>> How do you know I have not worked with both? Well OK, I haven't :)
>
>Somehow I knew that -- just like I know you are younger than I. But we
>have already concluded that my hunches can be wrong.

     Quite. Intuition is a wonderful thing, but it does have to be grounded.

[snip]

>> But here you are doing what you accuse others of. You have stated many
>> times that you find Pick satisfactory,
>
>I actually have a larger list of needed enhancements to such product
>than I have for Oracle, for example. But they are of a different ilk.
>
>> are looking for a persuasive
>> argument of the superiority of RM, and have not found one. In other words,
>> you are happy where you are.
>
>If I were happy with it, I would not have this angst. I am becoming
>more satisfied that my head-theory knowledge and budget-practice
>knowledge need not be so far apart. I thought I would rectify these by
>moving toward the RM in practice, but I'm going the other route
>instead. So, I am more satisfied than I was when I started asking
>questions here, but I would prefer to also be in step with the
>industry. So either I or the industry, likely both, have some distance
>to move before I'm happy where I am.
>
>> For many in this group the situation is
>> reversed, we are happy where we are in the RM (or Quasi-RM) and have seen
>> no persuasive arguments that we should move anywhere else.
>
>I understand.
>
>> Therefore if we are not qualified to judge, neither are you.
>
>Only to hold a dialog and see where we agree and do not. Those
>discussions are not fruitless from my perspetive.

     They do seem to result in, as Fabian Pascal put it, "grinding water."

>> <SNIP>
>>
>> >
>> >> First, the RM is perfectly suited to the task of CRM. This is because
>> >> the relation (or table) gives us the mechanism for storing details about
>> >> like items, while the miracle of the foreign key allows facts in one
>> >> relation to
>> >> be logically connected to facts in another. The discipline of
>> >> normalization allows a well-designed RM database to have the amazing
>> >> feature that "there is a place for everything and everything in its
>> >> place."
>> >
>> > yawn ;-)
>>
>> ???
>
>Sorry, must have been my mood. I should have said "point taken". I've
>just read too much RM propaganda lately.

     You made an offensive statement. Called on it, you retract it but give another. Not nice.

>> This is very telling. I've never doubted your sincerity before but now I
>> wonder. The fundamental task of the database theorist is to find a way to
>> store facts. The RM has this in a wonderful way. Why do you scoff?
>
>I shouldn't. I do agree that the RM does do a lot of this well. I
>will also fully support the RM approach of putting a mathematical model
>behind the discipline. I have no problem whatsoever using relations to
>model propositions, logic to do queries, etc. It is a combination of
>some of the implementation details in SQL-DBMS's plus the statements
>that we can't think of data in any other way that are problems for me.
>It is sometimes very helpful to have a tree or di-graph API, for
>example. I'm ready for SQL to be retired, but I would not want the RM
>retired, simply exhanced.

     SQL is not the RM.

[snip]

>> >> I think I've heard you mention Bible
>> >> study before, so I'll go at this one with a religious argument.

[snip]

>> Nope. The simplest correct model is the best model.
>
>OK. So, if my requirements for a model are that there be no visible
>ordering data that I need to see and/or manipulate programmatically
>when working with ordered lists, then would the RM be the best model?

     If you need ordered data, you can get that. If you do not care about the ordering, you can get that, too.

[snip]

>> > My claim was that this was another anecdote with a similar pattern to
>> > many others (but surely there could be other threads of similarity in
>> > them, such as those you suggest). My conjecture was that the data
>> > model change was a factor. It sounds like you are now saying it is
>> > "unlikely" rather than "cannot be taken seriously" so we are getting
>> > somewhere ;-)
>>
>> ....and as I said above, your conclusion in this case is clearly
>> pre-conceived.
>
>absolutely

     And thus, not a conclusion. Conclusions come AFTER, not BEFORE.

>> It has nothing to with what was actually written.
>
>although I could have some clues, however small, that are not in in the
>writing.

     That simply sounds like a variation of "The lurkers support me in E-mail."

>> If you
>> read the documents you would get a very different story. Whether or not
>> you like .Net, one clear concept coming through is that Reynolds tried to
>> build a huge system on a deadline with unfamiliar tools. Can you say
>> "triumph of hope over experience?"
>>
>> This throws into doubt your entire conjecture that there are "many others"
>> where data model was a factor. If you could come to such a clearly
>> irrelevant conclusion
>
>I would say that my conjecture isn't clearly relevant, but I don't know
>how you can say it is clearly irrelevant to the situation, even if it
>is not indicated in the story

     It is not up to us to disprove your conjecture. It is up to you to support it.

>> on this story, can we believe that the data model was
>> a factor in any of the other anecdotes in your portfolio? How many of them
>> will turn out, upon examination, to have some glaring flaw that has nothing
>> to do with the data model? All of them?
>
>Could be. I would love to know.

     Go find out then. You might find that you have been wrong all along and that you have a lot of crow on the menu. You might find that you have been right all along and that you now have ammunition. Seek and you may find.

>> Half? The burden is now upon you
>> to provide the first story where the data model was the culprit.
>
>I'm sure that isn't possible to do.

     An unfalsifiable hypothesis is not very useful.

[snip]

Sincerely,

Gene Wirchenko Received on Wed Aug 03 2005 - 19:13:41 CEST