Re: Just one more anecdote

From: dawn <dawnwolthuis_at_gmail.com>
Date: 4 Aug 2005 14:31:57 -0700
Message-ID: <1123191117.635536.270120_at_g14g2000cwa.googlegroups.com>


Kenneth Downs wrote:
> dawn wrote:
>
> > Kenneth Downs wrote:
> >> dawn wrote:
> > <snip>
> >> This leaves me with only one thought, and that is about hunches. I learn
> >> by both deduction and intuition, and have had many wonderful ideas I
> >> could not
> >> explain that turned out to be right. However, no matter how often I've
> >> done it, the next time I present an idea to decision makers they seem to
> >> think they are entitled to a reasoned step-by-step explanation.
> >
> > Even I require such reasoning before accepting either my own or
> > another's hunches as if they were fact.
>
> and yet below you refuse to provide any. case dismissed.

because I DON'T consider my hunches as fact -- I consider them hunches, to be put through the test before anything can be stated as fact. I try to be clear about what I state as hunch, conjecture, opinion, fact, ...  All can be stated or written. If I have been unclear, it was unintentional.

> <snip>
>
> >
> > You are taking one model of the data and turning it into another. If
> > the original data model can map to another, then I would like to be
> > able to work with the best one, or one of my choice, rather than
> > interfacing with the db products only by way of relations, for example.
> >
>
> Good luck. I'll repeat that I think you can have your cake and eat it too
> if you appreciate the role of layers in architecture, but I think the point
> will be lost.

but I agree with you! And then we should teach the variations in modeling data, right?

> >
> > I want the developer to say "here is a data model and it includes this
> > list" and then when that list is either tossed to a UI or a DB, it
> > "understands" how lists work with inserts and deletions, for example.
> >
> >> Again you are asking for a toolset.
> >
> > of course. I'm asking for a dbms that is not based on modeling data
> > only as relations.
>
> But why insist it be in the dbms if it is the layer above?

As soon as it is in a layer above that, then I'll just consider that my dbms. I was using the term loosely to refer to the various services of managing a database.

> I've snipped your hypotheses only because they aren't fleshed out. I'd be
> interested if you ever flesh them out.
>
> <snip>
>
> >
> >> Your hunch about newer projects is probably right. I'd bet money on it
> >> in fact, but your fixation on a single element, the RM,
> >
> > it is my biggest mystery related to s/w development right now.
> >
> >> is robbing all of us
> >> of any insight you can offer on the other elements.
> >
> > good technique, Mr. Downs :-) As much as I hate to admit it, I am
> > planning to start a column er, blog, this Fall because I do think I
> > also have some information and insights of worth. But I'm using cdt to
> > learn, not to teach.
> > cheers! --dawn
>
> Let us know when we can read the blog.

will do. cheers! --dawn

> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Thu Aug 04 2005 - 23:31:57 CEST

Original text of this message