Jo Anne Effect
____
'From:
kiyoinc@ibm.XOUT.net (cory hamasaki)
vr 13:12
Subject:
Re: The "Anne Jo" Effect
Jo Anne, Anne Jo, or ennA oJ... whatever. The problem may be in general
porpoise, uh, purpose (I'm getting tired of seaing, seeing, sea mammals
on TeeVee. and not enough episodes of Bay Watch with other kinds of sea
mammals... oh my, it's too late to be typing this...
The problem may be general purpose MIS systems that are customizable.
Some firms have fiscal years that don't match calendar years. A system
that works for them will also work firms that have fiscal years that
match calendar years. If the fiscal year does not match the calendar
year, you can't key simply on the digits of the year, the code must
generate the bounding years, months, and days, and do full comparisons.
I would guess that most systems are general purpose and do the full
comparison even though that specific firm is on a fiscal year = calendar
year basis.
While we're yacking, there are more than a few systems that key on
just the year and don't include the decade. Maxwell Online did that in
their main database. A few systems have bounding periods compiled
directly into the load module, purists like Shmuel might scream but
there are strange and wonderful things out there.
These are a few of the, I can't believe they did that, stories that Y2K
vets know about.
On Fri, 11 Sep 1998 02:32:58, ame1o@my-dejanews.com wrote:
>
> Tim, this is a good point, but having investigated this a little, I haven't
> found evidence of either the Jo Anne or your new analogous discovery.
> Although I'm sure they exist in other organizations.
>
> The issue is that a lot of reporting (e.g., against an Oracle backend) is even
> lazier than what Jo Anne, Cory, etc. have described, which effectively is:
>
> (date > 12/31/98) and (date < 1/1/00)
>
> which would definitely get hosed up. Instead, what I'm seeing is _grouping_
> based upon year, month, and/or day. That is:
>
> year(date) = 99
>
> This seems to work whether or not a four- or two-digit year is used. Since
> this is more succinct and many programmers (well... at least I can
> confidently speak for myself here) are quite lazy, I suspect that the
> grouping approach is used quite often.
>
> Also, in reporting (say, printing billing summaries for the fiscal year), you
> would end with a grouping approach for performance reasons. Such as:
>
> group level 1.... year(date) [=99]
> group level 2.... company [a..z]
> group level 3.... tot_out [z..a] (total outstanding)
>
> It's easier to optimize for this sort of report than a generic filter
> condition, IMO.
>
> For older systems that made it harder to compute a year for grouping
> purposes, I would expect the Jo Anne (and Anne Jo) effects to kick in.
> Hopefully this is a decided minority of cases.
>
> Cheers Bob
We'll see. We're really out of time, we've got to fix the truly
essential services. We also don't have the time to let the clueless
touch the code... it must be pros only from now on.
cory hamasaki 476 days...
|
