"Roy Hann" <specially@[EMAIL PROTECTED]
> wrote in message
news:T_adnWNsCqvQDP7V4p2dnAA@[EMAIL PROTECTED]
> "Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
> news:VEL8k.493$7%6.472@[EMAIL PROTECTED]
>> Not "getting" data is part of a larger problem, which is forgetting
what
>> software is actually for. Most end users couldn't care less about how
>> their solution is implemented, they just want a useable program.
>
> End-users absolutely do not care about anything except how easily they
can
> get through the 9-5. They don't own the business and they don't pay
it's
> bills and they have no investment in it's most valuable (and expensive)
> non-tangible asset--namely it's data. The end users' opinions on the
> subject of databases is as relevant as the cows' opinions on
> cheese-making.
You may have misunderstood as to who I meant by end users. Or maybe I
misunderstand by who you mean by "don't own the business". The end user to
me is the person who owns the database - it's their data...and presumably
also their business. Either that, or they work for the guy who owns the
data
and business. Seems to me that they do have an investment in the data.
>> Useable meaning reliable, not too hard to use, reasonably fast and so
>> forth. Not "getting" data is also accompanied by not "getting" user
>> interfaces, re****ting requirements, do***entation, error recovery etc.
>
> Not "getting" data means being a fraud and an imposter. No business
buys
> database applications just to run applications; they buy them to get
> accurate information and for no other reason. Not "getting" the other
> things you list means delay and awkwardness and you'll surely be in
> trouble if you can't deliver efficiency and speed, but those come
second.
> To prove it, propose to a company director that you can make his slow
> systems twice as fast but they'll produce undetectable corruptions of
the
> data, and see if he goes for it.
>
> Roy
I'm pretty sure that describing _any_ potential program flaw or deficiency
accurately and honestly to a buyer is going to result in no sale or a
demand
for a fix. You're right - if I told a potential purchaser that he'll have
a
responsive interface and beautiful re****ts, but that he really can't rely
100% on data integrity any more, he'd bail. But so too would he bail if I
told him that data integrity was assured, but that the user interface and
do***entation were so bad that the operators of the system would be highly
likely to enter an unacceptable amount of incorrect information. That is,
the information will be faithfully stored and retrieved, but it just won't
be meaningful.
As an example, I am reasonably familiar with a CRM system for a large ISP.
One of the functions of the CRM is to allow for quick description of the
nature of the interaction with the customer, in a fairly standard way -
department(s) who handled the interaction, main category for the issue,
subcategories, and a similar breakdown for resolution. IOW, a fairly
standard thing for a CRM. The databases are reliable enough, but the
interface for doing the above call-wrapping is so bad that interactions
are
simply not being correctly described. It's too difficult to find the
correct
categories/subcategories, the overall interface was very badly designed
anyway (something I frequently see with Web UIs), and in any case the
actual
choices are also not well thought-out. This is a classic GIGO
system...although one may be assured that the garbage will be safely
stored
and speedily retrieved.
So, is this a data problem, or something else? Some of it actually is a
data
problem, insofar as data also involves proper choices of acceptable domain
values, but a lot of it is a UI problem. Not much point in making it
possible for a user to do the right thing but ensuring that it's usually
easier to do the wrong thing.
AHS
|
