Re: Just one more anecdote

From: dawn <dawnwolthuis_at_gmail.com>
Date: 26 Jul 2005 20:21:23 -0700
Message-ID: <1122434483.482398.180490_at_g43g2000cwa.googlegroups.com>


Gene Wirchenko wrote:
> On 25 Jul 2005 19:24:48 -0700, "dawn" <dawnwolthuis_at_gmail.com> wrote:
>
> >I'm sure there are numerous factors playing into the fact that the
> ^^^^^^^^^^^^^^^^
> I suggest a general one below.
>
> >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.
>
> Probably irrelevant.

You certainly could be right -- are you basing this opinion on some particular experience you have had or just a general opinion without having developed systems in both environments or converted from one to the other?

One reason why I'll stick to my partial explanation (definitely not the whole of it) is that I've been involved in many migrations/conversions over the past quarter of a century starting with conversions from card systems to oltp and including conversions from one source code language to another and one OS to another. None has been so huge and difficult as the move to a SQL-DBMS environment from a very similar environment to what this vendor had. I can feel this one in my bones, brother.

> >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.
>
> Brook's Second System Effect
> (<http://catb.org/~esr/jargon/html/S/second-system-effect.html>) seems
> a likely culprit.

definitely not to be discounted

> >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 you are wrong or missing the biggest point, but not
> because of the PICK-SQL argument. Here is my take:
>
> How many software projects fail? I think we agree that the
> percentage is all too high.

Yup and I've read many treatices on such, none of which have implicated the SQL-DBMS. I don't know if I am the first to do so, but that is precisely what I'm doing.

> Original System was around for a while. It had made it over the
> hump. It was a successful system. That made it one of the elite. It
> may have been flawed, limited, whatever. No matter. It was a
> success, enough of a success to be used for some time.
>
> New System had not yet run the gantlet. It still had the
> opportunity to fail. (With the Second System Effect, it had an even
> bigger opportunity to fail.) It failed.
>
> You are comparing a successful system to a failed system. Apples
> and oranges.

Definitely two different systems, one of which was successful, but still worthy of comparison. In case you ever get a chance to choose between them, apples are often red and keep the doctor away while oranges are orange with vitamin C.

> I think that this hurdle would apply to any new system replacing
> an old one. I believe Machiavelli had something to say about new
> systems replacing old ones vs. a new system when there is no old
> system.

Yes, and I've used that quotation more than once, along with the old joke that God was able to create the world in 6 days because he didn't have an installed base.

However, you can refer to any system as a "first system". Why don't you point to the paper files that were replaced by the computer system as the first system, so that the one that the .NET/SQL Server app was supposed to replace would be the third. This new one would have been the first relational database application.

Again, there might be something to this line of argument, but it is not the entire picture either.

> In the first case, you have a conflict with those who like
> the old system that you do not have in the second case. (An example
> of this is the Pick vs. RM argument.)

Yes, I'm guessing there was some of that. However, I'm sure there were folks who liked doing everything on paper and not by computer when the first of these systems was implemented, likely many moons ago.

--dawn Received on Wed Jul 27 2005 - 05:21:23 CEST

Original text of this message