A: Neither
The great majority of non-compliant systems were intentionally designed as non-compliant in order to save coding time and hardware resources (CPU, memory, disk storage) at a time when these resources were several orders of magnitude more costly than they are today. Coding the systems as non-compliant was justified because:

• If the system were still in service in 2000, the initial savings in coding costs and the hardware savings reaped over the life of the system would more than outweigh the Y2K remediation costs.

• If the system were decommissioned before 2000, coding the system as Y2K compliant would have been an unnecessary and wasteful exercise.

Thus, the Y2K non-compliance of old systems was neither a "bug" nor a "design flaw":

• A "bug" is a program logic error that causes software to function in an unintended and undesirable way. Since the great majority of non-compliant systems were intentionally designed as non-compliant, their non-compliance cannot be called a "bug".

• A "design flaw" is an error or omission in design that causes software to lack a reasonably expected feature or capability. Y2K compliance was not reasonably expected in systems developed in the 1960's through the 1980's because it represented an unnecessary expense, as described above. Therefore, Y2K non-compliance was not a design flaw in systems of that vintage.

A: Nothing, if you're talking about net costs
Overall, the "Y2K Problem" had no net cost, for the following reasons:

• As noted in Q1 above, substantial economies were realized by coding old systems as non-compliant. These savings, taken over the lengthy life of the old systems, more than outweighed the cost of Y2K remediation.

• A large part of the money allegedly spent on Y2K remediation was actually used to:
  • Enhance old systems in ways unrelated to Y2K.
  • Create improved test environments and test procedures.
  • Develop new, improved systems to replace old ones (at a cost far greater than simply making the old systems Y2K compliant).

A: The "experts" who predicted disaster were not experts -- at least not experts in systems science, cybernetics, or anything rationally related to the Y2K issue.

Unfortunately, media people often prefer talking with a mountebank to, say, talking with a professor at MIT, the University of Michigan, U. Cal. Irvine, etc.

True experts always predicted only negligible Y2K problems.

False experts always predicted disaster, which makes sense, since it would be hard to sell books and video tapes titled "How to Prepare for Business as Usual."

A: No more than any other leap year.

The test: A year is a leap year if it is evenly divisible by 4, unless it is a centenary year, in which case it is a leap year only if it is evenly divisible by 400.

This is a very easy test to code, and it would take a real dufus to screw it up.

When people were doing their Y2K testing, they almost invariably included testing for February 29, 2000 date conditions as well.

However, assuming that people have neglected to code the leap year test properly, problems are still unlikely because:

• The shorthand test for leap years, which will function correctly for all dates between 1901 and 2099 inclusive, is whether the year is evenly divisible by 4. Note that both 2000 and 00 are evenly divisible by 4.

A: An organization's expenditures on Y2K testing and remediation were a function of how many of the organization's systems were (1) not Y2K compliant, or (2) not known to be Y2K compliant.

• Organizations with few computing resources would obviously spend little on Y2K compliance work. Many third-world countries fell in this category, as did many small businesses.

• Organizations whose systems were fully compliant (for example, turnkey software purchased from a vendor who certified compliance, or software known from earlier testing to be Y2K compliant) would obviously spend nothing on Y2K compliance work. Many second world countries and small businesses fell in this category.

• Organizations with systems of unknown compliance status who chose not to do Y2K testing spent nothing. They took a calculated risk, and in most cases did so intelligently. This category included mainly small and medium sized businesses, plus some third and second world countries.

Y2K expenditures were greatest in organizations with large, complex, date-sensitive, interlinked, and/or home-grown software. In addition, certain regulated industries, such as banking, were subject to considerable oversight from government agencies (the OCC, in the case of banks) which specifically required Y2K certification of critical systems.

A: Of course. However, they will be negligible, just as problems to date have been negligible.

• Given that not every single line of code in every single computer on earth was exercised within the first few weeks of January, it would be truly astounding if problems did NOT surface later.

• The Gartner Group suggested that less than 10 percent of the problems would surface during the two weeks around Jan. 1, 2000, while 55 percent would surface during the rest of the year. Accepting this as true, the number of problems still to come will be insignificant. By a principle known to most of us, a x b = 0 for every real number a, when b = 0. Thus, 5 times zero is still zero. And five times almost zero is still almost zero, if one cares to apply limits to this case.

• Generally, the later a problem is detected, the less important it will be. This observation follows from a major premise that important systems are those most frequently used. Given that problems to date have been almost ludicrous in their triviality, we can look forward to a further decline into the sink of absurdity. "243 Skunk Hollow residents receive incorrect water bills." Watch for headlines like that. Followed by knowing nods from Y2K doomsayers.