I have been trying to understand why people expect worse problems after the clocks roll over to the year 2000 as opposed to before. I think that it has to do with all of the components in our interrelated system that won't re-boot in the year 2000. This wouldn't be a problem if we just set the clocks backward, but the problem with that is that the component probably wouldn't have a clock in it if it weren't being used for something else in the system. So this is probably the complication that will make the time after the rollover especially difficult (on the hardware side).

I think that I am also observing another fact. It appears that the Y2K problems affect date related systems in direct proportion to their complexity. If we can find the most complex systems that have date related functions, I think that we will be able to look right at the systems that won't be done on time. This may help us work contingency and communicate to those who will be affected before the events occur. An analogy to this process might be weather reporting. As you get closer to the weather you are able to define more exactly what you see coming. This may help the planning process, and might even save some lives. It may also allow programmers who now know that they won't be done on time, to have a peaceful way of admitting it to their management.

-- Anonymous, May 20, 1999

Answers

Reporter, I found your "Musings" to be extremely interesting and containing very sound logic. I agree that complex systems are a good place to start when trying to identify y2k problem areas. I offer for your consideration a few other tidbits I picked up on my way to completing a y2k project:

1. The severity of a y2k bug depends on how the date is used. This holds true in both software programs and in embedded systems firmware.

2. The vast majority of intelligent devices use dates for - dates! Thats right, just plain old, everyday date/time information. (Repeat - information only, not actions, controls, or the like). This is the reason most y2k bugs in devices have only minor effects.

3. The majority of software applications use dates for - dates. Again, this is the reason most y2k bugs in software have only minor effects. 4. Software/firmware having y2k bugs that use dates for important functions such as calculations, control functions etc., almost certainly will have serious problems. (I have yet to find a date related system control function in the utility industry). Mission critical systems should be looked at first. This is what you must catch in your Y2K efforts!

5. Almost all Y2K bugs causing signficant problems are in software applications. Most firmware/embedded system y2k bugs are minor in effect - the reason? No date calculations or control on date actions.

6. An unusual exception to 1&2 above exists when a program contains non-standard date handling and/or poor error handling, coupled with the inability to handle year 2000 dates. In such cases, the program/device may indeed "crash".

7. 80-90% of a y2k projects efforts are spent on finding and fixing minor y2k problems, 10-20% on major. With only 7 months left, anyone who isn't almost done with their assessments should reverse this.

I have more of these Y2k'isms, if interested I will try to post for discussion. I believe that you are right on the money with taking a look at leasons learned, to see where to go in the next 7 months.

Regards,

-- Anonymous, May 22, 1999