A Veteran Programmer's Assessment

I have been a professional programmer since June, 1970 -- a bit over 28 years. Knowing fully well that it was going to be a problem, over that course of time I have written many programs, designed several systems that used two digits to represent the year in dates. Everybody who designed and coded software knew it was going to be a problem. So why did we do it?
     In 1978, the company I worked for purchased a state-of-the-art mainframe from IBM -- the fastest machine they could get at the time. It managed a network of 250+ terminals spread over 13 states, and handled 100,000+ transactions a day. It required 2,500 square feet of air-conditioned floor space. The system carried about five gig of hard disk and two megabytes of RAM. It cost about $2,500,000.
     Hard drive space was expensive. Carrying four digits for the year for the many dates that were recorded would have added to the initial cost of the system -- a single 330 meg hard drive cost tens of thousands of dollars. We made a decision to use two digit years to conserve on disk space and hardware costs. If we could have purchased a 11 gig hard drive for $300 like we can today, we would have made a different decision.
     The problem is real. Unless changed, some programs will be good and confused come January 1, 2000 -- some programs, but not all of them, not even most of them. Programs can be divided into three categories on the date issue: (1) Programs that manipulate dates such as calculating interest, (2) Programs that report dates but are unconcerned with their contents such as a web browser, and (3) Programs that don't give a tinkers damn about dates such as PKZIP. I think programs group about 10/60/30, that is, 10% care about the content of the dates, 60% report dates but don't care about their contents, and 30% couldn't care less about dates.
     This then reduces the magnitude of the problem. We absolutely positively have to fix the 10% that care about the contents of the dates, we don't have to mess with the 30% who don't care, and if push comes to shove, we can get by without addressing the other 60% and still get past the January 1, 2000 boundary without a hitch.
     Not only is the problem no where near as large as reported in the hype surrounding Y2k, the necessary fixes are extremely simple. This is not involved work. The problem is not difficult to diagnose nor difficult to fix. Programmers have tools available to them to make finding the change locations easy. This is the kind of work you can safely give to tyros straight out of school, leaving your senior staff to work on the hard stuff.
     With eighteen months left to go there's still plenty of time to get the job done. Don't panic yet. The average person will not notice anything other than a bigger than normal hangover from extra celebrating when January 1, 2000 rolls along. Programmers may spend some long hours for the first few days, but nobody else will notice.

To put it simply: Y2k ain't no big deal!

So why all the hype?

   Page created 07/18/98