Re: Discovering new relationships

From: Walt <>
Date: Wed, 07 Mar 2007 14:53:37 GMT
Message-ID: <RlAHh.11514$ig.1831_at_trndny01>

"paul c" <> wrote in message news:B0AHh.1241780$1T2.569684_at_pd7urf2no...
> mountain man wrote:
> > "paul c" <> wrote in message
> > news:2I4Gh.1209192$R63.892904_at_pd7urf1no...
> >
> >>mountain man wrote:
> >>...
> >>
> >>>Database systems theory can instruct you only to a
> >>>certain level about change management. Practice
> >>>on the other hand, with live and volatile and changing
> >>>data, will also instruct you in the more practical matters
> >>>of evolving relationships in changing schemas.
> >>>...
> >>
> >>This post reminds me of how much I think it is a shame how this group
> >>spends most of its time dispelling nonsense instead of suggesting
> >>progress. I agree completely with the first sentence above, but the
> >>second leads nowhere.
> >
> >
> > Are you suggesting that there is everything to be gained from
> > the theory of database systems, and nothing to be gained by
> > actually working hands-on with database systems which are
> > to be evolved and change-managed?
> > ...


> I didn't put my admittedly sarcastic attitude about this topic very
> clearly.

> As of ten years ago, most change management was seat-of-the-pants,
> ignorant of any theory, relying on adhoc rules-of-thumb or so-called
> "best practices", a euphemism for basically nothing, "applied" by a
> selection of mostly mediocre people from various disciplines. Being
> that way, they were mostly unaware of database theory. I suspect
> nothing about that has changed. If so, change management "practice" now
> lags a further ten years behind.

> The great value of theory is to make precise predictions. A layman
> might reasonably think that ought to be the main purpose of change
> management. I think you are confusing practice with application.


Here's what your last reply suggests to me (although it may not be what you intended).

There is a "theory of change management" that encompasses many different things that might change. Some of of those things are variable data structures. To some extent, the theory of change management was applied to the concurrent update problem in data processing by the development of the semaphore concept.

Database theory and change management theory intersect at several points.

Some people learn database theory formally, and this guides their practice. This guide is useful, in the sense that it allows the learner to learn of the existence and the danger of some pitfalls without having to learn about them "the hard way". The same thing I just said applies to change management theory.

Now some people will learn database theory formally, and change management by the seat of the pants. Mountain man seems to be addressing this case.

Some people will learn change management theory formally, and database theory by the seat of the pants. It would be interesting to know how they think, and what pitfalls they fall into.

Some people learn both by the seat of the pants.

Some people never learn.

And last, some people must learn both theories formally, and then get to apply them. I would suggest that anyone who is "trail blazing" will eventually get to areas that are not covered by any available theory, and will have to experience things that may later be formalized as a theory.

This post is too long, and I apologize. If I knew how to make it shorter, I would. Received on Wed Mar 07 2007 - 15:53:37 CET

Original text of this message