Re: Just one more anecdote

David Cressey wrote:
> "dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
> news:1122344688.525517.39350@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 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=1
> 611
> >
> > 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
> >
>
> From the above, it seems to me that this was an analysis failure, rather
> than a design failure.
>
> > 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.
> >
>
> Is the axe sharp enough yet, Dawn?

Inaccurate analysis on that one. I'm a future person, trying to figure
out how to do something better in the future based both on what I've
seen in the past plus what I learn about the orders of magnitude
differences in developer productivity from one project to another.
This includes topics as varied as how much limbic resonance exists
among project team members.

So when I hear another story like this one, instead of doing an
excellent historical study of it, which I would love to have -- where
is Bob Woodward when you need him? -- I think through what I have read
about project failures and what I have seen. Then I try, once again,
to put my finger on something related to the s/w application part of
the picture that would help future projects. I toss this conjecture
out here because so many people are convinced of the superiority of
relational databases (based both on college courses and sales figures)
that I would like to be convinced of it too. But I'm not, and I keep
coming back to this one little piece of the equation to see if we can
do better.

My Myers-Brigss varies, but more often INTP than otherwise. I haven't
read that description lately, but doubt it includes axes.

> > 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.
> >
>
> A good conceptual model is implementation neutral. Again, analysis, rather
> than design.

I'd like to think that is the case. Can you point me to one good
example of a conceptual model for a system that is not tiny?
>
> > 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.
> >
>
> You are assuming a fact not yet in evidence.

Yes. I made a conjecture based on something less than omnipotence.

> > smiles. --dawn
>
> Is this your way of hinting that you are just jerking the chain on the
> denizens of this NG?

My comments are wrapped in a smile -- perhaps my way of letting you
know that I know I don't know everything and I know many will disagree
with me. I believe what I write when I write it, but I want to bounce
the thoughts off others in order to learn. I really, honestly, scouts
honor, jumped into this newsgroup thinking people would convince me of
the benefits of using a SQL-DBMS so I could shake my sense that such
tools have done some significant harm to s/w dev productivity, and I am
very surprised it has not. I have learned a lot, however, and more
each time I offer an unpopular opinion.

In order to get good, interesting, informed, alternative opinions from
people like you, perhaps sometimes I lure you into my lair.
smiles. --dawn

.

Relevant Pages

  • Re: Just one more anecdote
    ... >>subsequent logical data model from which the original system was ... >>developed would not play to the strengths of the SQL-DBMS. ... > You are comparing a successful system to a failed system. ... > I think that this hurdle would apply to any new system replacing ...
    (comp.databases.theory)
  • Re: Modeling Data for XML instead of SQL-DBMS
    ... Storage is irrelevant when talking about the logical data model. ... modeling outside of the SQL-DBMS environment. ... sufficient graphical syntax, it's designed for software design, not database design. ...
    (comp.databases.theory)
  • Re: Modeling Data for XML instead of SQL-DBMS
    ... data model be in 1NF or the use of the SQL NULL. ... modeling outside of the SQL-DBMS environment. ... a good way to approach the design for this data? ...
    (comp.databases.theory)
  • Re: Just one more anecdote
    ... than a design failure. ... > subsequent logical data model from which the original system was ... > developed would not play to the strengths of the SQL-DBMS. ... > we might want to think otherwise, even the design of a conceptual data ...
    (comp.databases.theory)
  • Re: Modeling Data for XML instead of SQL-DBMS
    ... documents and not in an SQL-DBMS, the tools would not require that the ... How would an excellent logical data model designed for this XML ... XML documents compared to data modeling for a SQL-DBMS? ... Using a broad definition of "database" the XML documents, in this case, ...
    (comp.databases.theory)