The idea that moving into a year which has a number followed by 3 zeros, has struck various amounts of awe, fear, born againism and whathaveyou into various facets, categories and strata of societies since the late 900's. Hopefully, the outlook of the late 1900's is somewhat different to the outlook from the mid 900's.
My own predictions for the impending turn of the century, is that few (if any) virgins will be sacrificed, few (if any) elements of the upper echelons of the food chain will have their entrails read, and any company using outdated or poorly designed software, COULD become ancient history shortly thereafter, unless time and budget is reserved for investigating the impending technological solstice.
It is a well known fact that good news does not sell as readily as bad news. So let me put some bad news perspective into this foray:
Historically, when data storage and computing cycles cost lots of money, every imaginable artifice was employed to contract the amount of space required for data. We all still live with the MS-DOS constraint of 8.3 characters - I seem to remember the last 3 bytes were with exceptional technical wizardry, made to occupy 1.5 bytes somehow. The reasoning for this was akin to the reasoning of 640KB for MS-DOS memory constraints, (who would ever need more than 640KB of memory etc!). This approach pervaded computing circles until the 80's. BASIC, COBOL, assemblers etc., were all of the bent that 2000 was too far away to be concerned about, and the designers (back in the 50's) would not be around to be sued then anyway!
Modern languages (typically 4GL's and languages developed since the late 70's), have been written by people with larger egos': developers expected their work to outlast them. Consequently, these updated products do not have INHERENT incapacity hidden away inside there entrails. Unfortunately the converse is also true: newer products do not necessarily have an INHERENTLY correct capacity for avoiding the change simply because the technology is current. Life is not that simple.
Concentrates the mind
This INFERENCE is of course the meat and potatoes of what all the fuss is about.
Ask 100 programmers to write a run of the mill order entry sub system, and without doubt, you will eventually get 200 or more sub systems (any programmer worth any salt will never be content with a first pass at anything). The issue here is NOT that the system compiling engine is in any way lacking, it is that the analysts and programmers may overlook certain aspects of performance. The bare fact that dates are stored as YY/MM/DD does not necessarily mean that the system will give up to the grim reaper of 1999 and be consumed into the residue of systems past. NOR does it mean that "modern" systems are immune to these hazards.
The straight truth is that if the system is designed with the philosophic constraint of requiring the 4 digits of the year into the code, then there will (probably) be no significant melt down. Two (or three) digits will not cut the potential millennial impasse. This of course must be taken in the context of E&OE*
For example, all those years ago when I began to actually sell my designing and coding capacity as a BASIC programmer (and of course having an insufferably large ego), all systems had date details stored as integer fields of YYYYMMDD. Similarly, time was stored as HHMM on a 24 hour clock. To ensure that the most recent events were displayed on top of the scan, the YYYYMMDDHHMM field was inverted, simply by subtracting it from 999999999999. This was then used as a significant part of the indexes. Not exactly sophisticated, but very effective, and has worked very successful. The point being that even with a prehistoric BASIC system, avoiding the much feared black hole of the next millennium, WAS possible; even with minimal resources.
Working with 4GL's for 6 years has also enabled me to see similar (if opposite) possibilities with new processing languages. Unfortunately, exactly the same problems are possible under these "safe" languages, once again if the full implications are not allowed for, a user can enter 2 digits for a year, and unless there is a century default, then the year 1996 will be entered, saved and indexed as the year 96; does this sound familiar?
The problem then would appear not to be one of technology or lack of it, but more of one relating to analysis, design and coding. The buck finally stops, where it belongs: at the application and its creators, NOT because the "best by" date has passed on older technology.
We have now established that bad news exists, and this magazine will thus sell out and need reprints.
My next article will outline how companies can address these issues and achieve a trial balance on January 31st. 2000 (E&OE of course).
* E&OE = Errors and Omissions Excepted: LawSpeak for "If I'm wrong it's still your problem, not mine".