Re: It is okay for things to break in the future!

I remember a time when I was involved in designing an application that
should work with events focused on future dates.

Someone desperately wanted to have some validation on the future dates, so
we put a rule, something like Year(date) < 9000

Another person asked: "Maybe our descendents in the year 9000 will hate us
for this code?"

The answer to this is: "This will be absolutely great, because it will mean
that: 1, humanity was able to live up to this date, and 2. Our application
was still used that far into the future"

This means that maybe it is wrong to speak about the future in general.
There is the nearest future, about which we may be concerned, but any
attempts to even imagine a later future would be meaningless and
unjustified.

Who could imagine in the 70-ties that we will have the Internet or mobile
phones? I don't think any of our applications will be used 100 years from
now, except maybe implementations of numerical /mathematical algorithms,
which by definition are time-independent.

Thus, money spent on making an application (generally-)future proof is most
likely money that could be put to something much more useful in the present.


Thanks,
Dimitre


On Sat, Sep 3, 2022 at 3:45 PM C. M. Sperberg-McQueen <
[email protected]> wrote:

>
> Michael Kay <[email protected]> writes:
>
> >>
> >> This is a really, really common mistake made by inexperienced
> >> developers - we used to see this all the time in phone number
> >> formats, for example. Then mobile numbers came along and changed the
> >> formats. And international phone calls became really common,
> >> necessitating country codes as a standard part of phone numbers. Etc
> >> etc etc :)
> >>
> >
> > I have had to invent an imaginary US phone number before now in order
> > to get past such stupid validation rules.
> >
> > A golden rule of validation - never force your users to enter
> > incorrect data in order to get past your validation rules!
>
> On a more sombre note, consider the tradeoff between the benefits of
> having data that's clean according to some rules and the costs of making
> data fit those rules.  In 1996, when a bomb threat was called in
> regarding a bomb at the Olympic stadium in Atlanta, the 911 operator
> spent ten minutes trying to make the 911 system accept the report --
> "Centennial Park" was not accepted as the location of interest, because
> the system was programmed to require a valid street address with street
> name and number.  (I had the same trouble trying to report an apparent
> car accident in Baltimore's Druid Hill Park once; the dispatcher could
> not enter the report without a street address, so after explaining the
> problem I made one up.  In the county where I live, a significant number
> of voter registration records have location information like "white
> house 3/4 mi southwest of intersection of US 84/285 and NM 399" -- a
> data validation routine that expects a house number followed by a street
> name is going to be worse than useless.)
>
>
>
> --
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> http://blackmesatech.com
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: [email protected]
> subscribe: [email protected]
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>