Re: database systems and organizational intelligence

Comments embedded.

"Laconic2" <laconic2_at_comcast.net> wrote in message

> > Doesn't this imply the intelligence lies within the developer/solution
> > provider? If they know the purpose (the what and how) of the task, they
> > pick the language that minimizes the distraction from the task; for
> language
> > is nothing more than a tool.
>
> Very interesting.
>
> I think of the specification of the task as the WHAT, and the
implementation
> as the HOW. I'm not sure where purpose fits in, although it clearly
does.

Yes. The purpose is very important...very similar to goals, but broader in nature. It's the WHY we're doing the WHAT and HOW we're doing it. :-)

I think when we understand the WHY we can direct the WHAT and HOW. I guess if my job doesn't require it, to know the WHY, I do what I'm told. I think we'd agree the more we know the closer to the WHY we get and the better the design and implementation will be. We're more experienced and knowledgable.

> It seems to me that "writing an A/P check" is a different task from
> "developing as system that writes A/P checks".

I agree, at the task level. The actual creation of the check (either physically or in the database) is just one of many tasks within a check-writing subsystem.

If we understand WHY we would want to create an A/P check and WHY it relates to the accounting and financial reporting as a whole we're much more likely to efficiently develop this individual task and small subsystem.

[snipped]

> Incidentally, I would think a "language specialist" would be much too
> narrow a scpecialty wouldn't you? That's why I substituted "system
> specialist" for "language specialist".

Ok. What bothers me, though, is the language. There are many languages and IT structures (databases included) that seem to be disassociated from many solutions. When we're trying to develop a simple A/P check-writing subsystem, we seem to constantly encounter digressions: data typing, 1NF restrictions within the data, array conversions, variable scoping, memory access, and on and on.

A database is such a natural part of a business application it's hard when the dbms is so distracting. Obviously, the less distraction there is with language and dbms tools the more likely it will be we can directly apply business knowledge to applications. I think this would create more stable and longer lived applications.

> Don't all professionals pick up more languages over time?

Yea, but I drop the old ones just as fast. I always refer to this phenomenon as the language de jour. :-) Received on Mon May 31 2004 - 12:43:13 CEST