Re: [xml-dev] It is okay for things to break in the future!

[Dimitre Novatchev <dnovatchev@gmail.com>]

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 <cmsmcq@blackmesatech.com> wrote:

Michael Kay <mike@saxonica.com> 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: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php