Re: Upgrade as Change in Meta-state

From: Laconic2 <laconic2_at_comcast.net>
Date: Thu, 21 Oct 2004 22:06:03 -0400
Message-ID: <otednRIn4eiL9uXcRVn-sQ_at_comcast.com>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:7ei9lc.n3s.ln_at_mercury.downsfam.net...
> Laconic2 wrote:

> From a vendor's point of view, selling the EDS, we push that definition
off
> to you. The idea is to make it as powerful as possible, so that you have
> as much flexibility as possible.
> >

I'm not following you here.

> Brush up on our XML skills? (ducking)
;-)

> If you want to change it I'll give you the source code under the GPL, you
do
> whatever you want with it. Paying customers are those who desire the
> service of an outside vendor or that vendor's established package.

>
> >
> > You provided me with a "maximum salary" parameter, and it's childishly
> > simple to update that parameter. Great!
> > But now the Gubbermint shows up, and tells me that I have to implement
a
> > "maximum value of stock options" in addition to a maximum salary, and I
> > have to do it withing 90 days. I call up the sales person at your
> > company,
> > who says, "Gee we never thought of that! Wait for the the next
release!"
> > "When is that?". "Two years form now".
> >
> > Do you see the problem?
> >
>
> Do I see it? The express purpose of this approach is to accept it,
embrace
> it, love it. There is no such thing as the finished product, it will
> always change, that's why changing it must be easy to do, and easy to
> manage.

Beg pardon, but I don't think you did see the problem. The Gubbermint is going to shut my enterprise down in 90 days if I don't revise my business processes to confrom to their laws, and if I wait for your next release, I'm waiting two years.

That means I have no choice but to sink or swim on my own. I'm back where I would have been if I had built my own database.

> > I'm with Tony on this one. This would never fly at my shop.
>
> (ducking) um, if it would never fly, why are you working on the diff
engine?

Well, maybe I didn't make this clear. When I built the diff engine that I described in the other thread, it took all of one day's work. It was a lot less ambitious than the one you are working on. That one day's work was as a consultant (or contractor if the term "consultant" raises your hackles) at a client's shop. It was their database, built by them, and diverged by them by two of their DBAs, working on opposite sides of the pond.

My task was to identify the divergencies.

BUt all of this is leading me away from the direction I wanted to take the topic.

I think you and I have got very different views about database support. At almost all of my client's shops, the database was an in house product, not something purchased from a third party.

So they were building directly on top of the DBMS.

That's very different from the world of clients you produce for. It almost sounds like your clients don't do their own programming, or revise and extend your database. (except withing the parameters you set). That's a foreign world to me.

So I'd like to learn what I can about that world in this topic.

Have you ever worked as an employee for a company like one of your customers? How do the terms you have laid out strike them? Received on Fri Oct 22 2004 - 04:06:03 CEST

Original text of this message