Re: Just one more anecdote

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.

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

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.

> >
> > It is very likely that the conceptual data model and surely the
> > subsequent logical data model from which the original system was
> > developed would not play to the strengths of the SQL-DBMS. As much as
> > we might want to think otherwise, even the design of a conceptual data
> > model is influenced by the designer's knowledge of the target dbms. A
> > redesign of the data model for a SQL-DBMS is likely to both bump
> > features and increase complexity -- a harsh one-two punch.
>
> I'll be happy to go head-to-head with you here.

Please, please, tell me how we can set up that head to head so that we both end up understanding something that we didn't understand before.

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

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

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

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

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

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

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

> Sit down with all the stakeholders and
> turn brainstorming directly into table design. As form follows function,
> the rest of the system will follow the table design, and the development
> process and tools will assist in that development workflow.
>
> Another point is that the RM is perfectly happy with hierarchies, although
> SQL decidedly is not. Sigh.

One thing I have definitely learned here is that SQL and the RM do not align all that well.

> So I bring all of this up for two reasons. First is to state emphatically
> that your original claim regarding SQL-RDBMS was very unlikely to be true
> because it considered so little of the world.

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

> But my second point is to
> avoid the unspeakable bad taste of critizicing one view without providing
> an alternative, so that you may likewise criticize mine. Long live the
> dialectic!
>
> >
> > My conjecture is that downgrading, I mean moving, from a graph data
> > model to a relational data model and from a PICK dbms to the SQL-DBMS
> > were significant factors in this project failure. I could be wrong, of
> > course.
>
> I think that you are sincere and have put your finger on something, but that
> you have missed that something and have come to the wrong conclusion.

I will grant that as a possibility and continue my quest.

> My reading of the project description finds a great deal of drum-beating for
> the .Net conglomerate, suggesting heavily that the project was driven by
> political goals, not technical. When this happens it is like sacrificing
> freedom for security, you get neither. Also, if the project really was
> politically driven, then it probably was a downgrade.

In all of my years in IT, I have never seen a project that wouldn't be considered "politically driven" even those I have championed. Politics is not a bad thing, depending on definition. I "play politics" when I believe in something as good for the future of the organization or society or whatever. If someone made pitches for .NET, they likely (but not necessarily) believed it would be good for the company. Cheers! --dawn

> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Tue Aug 02 2005 - 03:11:55 CEST