"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. 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.
There is a larger problem, as you say, about not getting what software is
for. Or, generalizing some more, not getting what systems are for. But
my
interest, in this discussion, is programmers who do get it about the
software systems they build but don't get it about the data their systems
manage.
Whether a useable program conceals all the data from the user or reveals
appropriate data to the user depends on the context. When I drive a car,
I'm a user of a system under the hood that controls the gas-air mixture.
If
it protects my engine, delivers better power, and improves gas mileage,
I'm
happy. I could give a lesser about the data it uses. But there are other
systems where the handling of data is critical to the useability of the
system.
>
> One job I worked at involved property management software. We didn't
write
> the stuff, we had to access the backend data for the various
applications
in
> use. Some apps used databases, some used files. Let's just say that on a
> scale of 1 to 10 not many of these programs rose above a 5 on any
objective
> criterion. The treatment of data was often particularly bad. As an
example,
> how can you have a system that has as one of its main purposes the
> management of rental information, that only provides for the entry of
> personal information about one tenant? Guess how the typical landlord or
> property manager is going to store information about two or three
people?
> That's right, any way that works...like stuffing three last names into a
> single surname field. One application at least anticipated that there
might
> be multiple tenants - they provided six separate fields to account for
the
> first and last names of up to 3 people...not exactly a stellar solution.
And
> these apps often featured what I call "just in case" columns in their
> tables, columns labelled like Info1, Info2, Info3 or suchlike, not
> infrequently exposed to the end user, and not surprisingly used by the
end
> user in very personalized ways to store data. In other words, dangling
data
> as far as standard (anticipated) retrieval was concerned.
>
> This wasn't a failure of "getting" data - this was a failure to "get"
> practically anything.
>
I disagree. The "up to 3 people" case is clearly either a failure to
understand first normal form or an unwillingness to decompose records for
one reason or another. That's not getting data. The dangling data
exposed
to the user for unanticipated purposes is a sin that I've committed
myself.
It's only a sin when management later expects re****ts that aggregate
idiosyncratic data.
Which is every single time.
In a way, OTLT, where this discussion started, is a way of dangling some
columns where users (or perhaps programmers) can define any reference data
they want, so as to accomodate unanticipated codes.
|
