Re: Upgrade as Change in Meta-state

"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:451alc.ogt.ln_at_mercury.downsfam.net...

> The customer can treat the EDS as a black box, as you have described, or
> they can blur the distinction and begin to manage it like an IDS. They
can
> do this because they have not been "bamboozled" as you put it in another
> thread. They could completely take over development if they wanted to.

OK, this clarifies it for me.

It also brings back to my mind that in at least two of my experiences as a contractor/consultant there were two teams. The "production side of the house", and the "development side of the house." Their relationship was pretty much like the relationship between vendor and client that you describe.

There is no way the production side of the house would have taken on responsibility for a "black box EDS". Not ever. There is also no way the development people were going to start wearing pagers and come in on weekends. Not ever.

So here's the arrangement they came up with: The production DBAs can diddle with the database all they want to (pun intended). They can add tables, columns, indexes, add or remove constraints, whatever. Production maintains a test system. If a failure is attributed to the database, it's the job of production to come up with a workaround on the fly, (as in "we CAN sell you this radio, although the computer says it doesn't exist!") and also to recreate the problem on the test system, using the STANDARD database as released by the developers.

If the problem can be recreated, then this problem is turned over to development to repair. And they may have to pull people off their regular duties to get that done.

If the problem CANNOT be recreated on a standard database, then it's production's problem to solve.

This is not perfect, but it works.

And I think it means we can move on without further debate on this point.

> I do see the problem, but I didn't explain my approach, my bad. I think I
> conveyed my enthusiasm without conveying the solution.

OK. While I have remaining questions about your approach, they are a separate issue from the main issue.
I'm going to say "nolo contendere" on this one.

> I can offer you an example of how this approach has worked out in
practice.
> A certain unnamed company bought the software produced by a certain
unnamed
> former employer of mine. They liked a lot of stuff, but they hated a lot
> of stuff, fairly normal. But upgrades were a particular problem with this
> package, it would take them 2 days (!!) to upgrade the test system, only
to
> have it ultimately fail! This happened nearly every time. And everyone
> knew that they could not reproduce the upgrade on the live system. When
> my upgrade tool went online they got, on the first try, an unattended
> upgrade that went perfectly and was logged and reproducible. They loved
> that, it changed their lives and their experience of the product.
> Cupholders and moonroofs.

OK. I'm going to accept this in the same spirit as I accepted Bernard Peek's claim that XML reduced to finger pointing battle to a problem of analysis. It works. Received on Fri Oct 22 2004 - 15:52:18 CEST