Re: Just one more anecdote

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
> >> >
> >> > This is yet another instance where a legacy system written with a PICK
> >> > (in this case), MUMPS, IMS, or other pre-relational database product
> >> > didn't successfully make the jump to a SQL-RDBMS.
> >>
> >> I may agree if we phrase it more precisely:
> >>
> >> "This is yet another instance where a _stable_ system ... did not
> >> successfully make the jump to a completely new data model, software
> >> architecture, hardware architecture, operating system(s), set of
> >> programming languages, and (most likely) much younger and less
> >> experienced body of programmers, with an almost certain lack of serious
> >> input from the designers of the original system."
> >
> > I'll agree with that, of course.
> >
> >> In other words, pinning it on the data model ignores more or less the
> >> entire software development process.
> >
> > If I pinned it on that, I would agree. I have no doubt that are many
> > variables. Project & process issues play a significant role in most
> > project failures. I forget the author who rather recently wrote that
> > in spite of such issues, more s/w projects still fail for reasons of
> > performance (as in speed) than any other issue.
> >
> > 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.

> 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?
>
> >
> >> I'll be happy to offer anecdotes surrounding
> >> every other item I've listed. But the statement as you wrote it cannot
> >> be taken seriously.
> >
> > 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 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.

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

By the way, it isn't that all people who have would pick the 40-year-old pick environment over a SQL-DBMS. I have picked SQL-DBMS projects over this environment based on a requirements analysis (need for SQL reporting tools tends to lean that way).

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

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

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

> >
> >> Methinks perhaps that you can only appreciate 1NF if you appreciate the
> >> above.
> >
> > I thought the group largely agreed that 1NF was meaningless in the RM
> > at this point. What is your def of 1NF?
>
> Not me. I participated little or not at all in most of the 1NF arguments
> because I am old-fashioned and find Codd's original 1NF to be just fine.
> If you want a list, put it in a child table, that's what they are for.

Well, it is good to know that I'm just arguing with a straw man on that one.

> >
> >> Then I boldy state Downs' law (completey w/o proof of course): People
> >> find it easy to work with tabular data.
> >
> > I'll agree with you on that.
>
> How can you agree with this and give me a "yawn" on my description of the
> benefits of the RM? Are you an MBA? (ducking)

My tables might look different than your tables. Sometimes I have ordered lists in cells ;-) No MBA here, just a MOM.

> >
> >> I think I've heard you mention Bible
> >> study before, so I'll go at this one with a religious argument.
> >> Question: what is the simplest explanation for the fact that all human
> >> societies have religion, and that all human societies believe in a
> >> creator that is outside
> >> creation? Answer: The simplest answer is that their belief is true.
> >> Everything else introduces complications to protect a pre-conceived idea,
> >> and the complications pile up like epicycles in Ptolemy's solar system.
> >
> > I enjoy reading apologetics and think it a brave sport, but you won't
> > catch me going that route.
> >
> > You are using "the simplest model is the best model" and I don't buy
> > it, although I don't dismiss it as useless.
> >
> > Are you a Unitarian? It certainly provides a simpler model for God
> > than any Trinitarian view, right?
>
> 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?

> I am a Trinitarian because that view is the simplest explanation of what we
> know about and have experienced of God. Unitarianism is not likely to be
> correct because it must ignore so much of the story to get itself
> comfortable, and so it does not matter to me how simple it is.

Good.

> For that matter, the theory that there are only four elements, Earth, Fire,
> Water and Air is surely simpler than the current Standard Model of particle
> physics, except that it is wrong, so who cares how simple it is?

good example

> But to the matter at hand, one of the simplest explanations for the
> widespread acceptance of the RM is that it is useful.

and it definitely is

> Just as in
> apologetics, this simplest explanation must at least be considered, even if
> it is found later to be false (as in the 4 elements). It seems to me you
> refuse to consider the simple possibility that the RM is more useful than
> you think, because you cannot appreciate the simplest things about it.

I appreciate the RM more than I must let on. I really think it has a lot to offer. I have even taught it to others, like a good disciple. I have some issues with it, however, and I'm not alone in that.

> >
> >> Now by extension I would ask why it is that so many people find it so
> >> self-evident that the RM is valuable?
> >
> > Hey, even I find the RM valuable. I certainly appreciate the set
> > operations, for example. I'm looking for biggest-bang-for-the-buck
> > approaches, not just any one that might be valuable.
>
> What do you mean? How is it useful?

In general, I would rather write and maintain set operations on relations than looping and navigating til end of file, for example.

> >
> >> The simplest answer is that the RM
> >> really is valuable. I also state for the record that your insistence on
> >> non-atomic data (ie, breaking 1NF)
> >
> > that answers my prior question -- so you are still in the camp of 1NF
> > including no repeating groups, right? That is an area that I think by
> > now we have covered with very logical detailed analysis and with
> > somewhat general agreement that 1NF, as we knew it, is now dead in
> > theory, even though not in practice. You disagree?
>
> The wonderful thing about this free world of ours is that I can do what I
> want. Since I can put repeating groups into child tables and query them
> there, I see no reason to represent repeating groups by some other
> mechanism as well.

Yes, you certainly may.
> >
> >> is an epicycle in the Solar System,
> >> meaning it is a complication introduced to try to fix a basic
> >> misunderstanding of how things are put together.
> >
> > Recognize that I'm talking about the logical model not about how things
> > are put together. What is the API? Can we talk about a human being as
> > a whole or must we partition it into smaller components?
> >
> >> A direct consequence of Downs' Law is that the best way to design a
> >> system is to go directly to table design.
> >
> > Again, I wish I had your clarity on that one.

My tables are more like record sets, yours are more like row sets.

> I've certainly tried to share it with you :) For instance, I explained it
> above and you yawned. If you can't get past the yawn, you'll never
> appreciate the RM.

With any other audience, I would be clearer in my appreciation of the RM. I still haven't decided whether all of my issues are with SQL and the implementations of the RM. At this point I think that the RM might be necessary but not sufficient, but I'm still poking it with sticks to try to figure that out.

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

> It has nothing to with what was actually written.

although I could have some clues, however small, that are not in in the writing.

> 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

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

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

> Now I ask with all respect, why is it that you are so fascinated by the RM
> that you keep coming back?

Because what I learned as theory and saw as practice didn't square up. If I didn't care about theory, then I would disregard it. If I could blow off the experiences as abberations, I could disregard them. I can do neither, so I have an internal conflict.

> Are you like the atheist that never stops
> talking about religion, hiding a desire behind a criticism?

No. Atheists have a religion -- atheism. I'm a "seeker". I'm trying to find a theory and gain experiences that are in synch with each other, rather than in conflict. My goal, as I've mentioned on several occasions, is big-bang-for-the-buck application software development. I know it can be better than LAMP (for example). I have some hints and no proof, that the data model makes a difference and that applications written using the RM to date (all SQL-based) have caused the cost of ownership to rise, not fall.
--dawn

> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Wed Aug 03 2005 - 04:22:07 CEST