The typical expectation when it comes to IT software services is that programmers and technicians will work to provide the most seamless experience possible.

This usually means that software tools will be free of errors that could potentially cause major problems for businesses in certain use cases, such as databases that reach a certain huge number of entries or analysis tools that have certain date or macro limitations.

However, some very popular and widely used software packages leave in certain errors on purpose for stability and compatibility reasons, with their removal often causing more problems than they solve.

This is known as “bug compatibility”, and whilst it is not necessarily desirable, it is often somewhat necessary in order to maintain cross-compatibility and backwards compatibility with certain older systems, which in turn often retain bug compatibility with even older systems.

A rather notable example is the 1900 problem. Early spreadsheets calculated leap years by seeing if it was divisible by four, given that a solar orbit is 365.242199 and not 365.25 days, not every centurial year is actually a leap year.

Only centurial years that are divisible by 400 are leap years, so 1900 and 2100 will not be leap years but 2000 was.

Microsoft Excel uses, by default, a 1900 Date System which records dates using a floating point system but intentionally accepts 29th February 1900 as a valid date, despite this date not existing.

The reason for this is to maintain compatibility with the most successful spreadsheet software on the market when Excel was launched, Lotus 1-2-3.

Microsoft themselves noted that whilst it could be fixed, it would change the dates in all spreadsheets and documents that rely on dynamic dating systems, as well as break functions such as WEEKDAY.

Because so many systems have been built with compatibility in mind, they also need to be compatible with bugs, errors and mistakes, unless the benefits of fixing the bug outweigh the potential drawbacks.