Re: Upgrade as Change in Meta-state

Laconic2 wrote:

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

>> to you.  The idea is to make it as powerful as possible, so that you have
>> as much flexibility as possible.
>> >

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.

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

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

>> > "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,

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

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

A system upgrade can be Incremental or Complete. In a dictionary based, diff'ing system, you can provide a "patch" that is composed of a description of, for example, two new tables and few new columns in existing tables. The system adds this to the reference spec it already has, runs a diff, and generates the new tables and code. If it were a big patch perhaps we're talking 20 new tables. Whatever it takes.

No waiting for a release.

But better yet, no stepping on this patch when the new release comes out.

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

I usually do not explain any of this to a client, anymore than Toyota explains their engineering methods to me. They show me cupholders and moonroofs and I show customers flexibility, power, and convenience.

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.

I have worked only once on the inside, but it was just out of college and really does not count.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me