{"id":36,"date":"2006-10-26T11:38:00","date_gmt":"2006-10-26T15:38:00","guid":{"rendered":"http:\/\/2d823b65bb.nxcli.io\/2006\/10\/the-chernobyl-design-pattern.html"},"modified":"2010-03-18T11:26:13","modified_gmt":"2010-03-18T15:26:13","slug":"chernobyl-design-pattern","status":"publish","type":"post","link":"https:\/\/www.robweir.com\/blog\/2006\/10\/chernobyl-design-pattern.html","title":{"rendered":"The Chernobyl Design Pattern"},"content":{"rendered":"

In 1994, the world learned that the Intel Pentium chip had a bug. In certain cases it gave the wrong answer when calculating floating-point division. These cases were rare, only 1 in 9 billion divisions, and typically only resulted in errors past the 8th decimal place.<\/p>\n

What did Intel do about this? Well, there was denial at first, and then dismissal of the problem as being trivial and unimportant. But eventually they saw the light and offered a no-questions-asked replacement policy<\/a> for defective processors. No doubt this was expensive for Intel, but this preserved their good name and reputation.<\/p>\n

It could have been different. For example, they could have simply kept the bug. They could have preserved that bug in future versions of the Pentium for backwards compatibility, arguing that there was some software out there that may have worked around the original defect, and for Intel to fix the bug now would only break the software that worked around the bug. This is a dangerous line of reasoning. What bug can’t be excused by that argument?<\/p>\n

Intel could have further decided to turn their bug into a standard, and get it blessed by a standards development organization and maybe even ISO. \u201cIt’s not a bug, it’s a standard\u201d.<\/p>\n

But Intel is not Microsoft, so they don’t have quite the audacity to turn a bug into a standard, which is what Microsoft is attempting to do by declaring in Office Open XML (OOXML) that the the year 1900 should be treated as a leap year<\/a>, in contradiction of the Gregorian Calendar which has been in use almost 500 years. (Years divisible by 100 are leap years only if they are also divisible by 400)<\/p>\n

By mandating the perpetuation of this bug, we are asking for trouble. Date libraries in modern programming languages like C, C++, Java, Python, Ruby all calculate dates correctly according to the Gregorian Calendar. So any interpretation of dates in OOXML files in these languages will be off by one day unless the author of the software adds their own workaround to their code to account for Excel’s bug. Certainly some will make the \u201ccorrection\u201d properly, at their own expense. But many will not, perhaps because they did not see it deep within the 6,000 page specification.<\/p>\n

There is something I call the \u201cChernobyl Design Pattern\u201d, where you take your worst bug, the ugliest part of your code, the part that is so bad, so radioactive that no one can touch it without getting killed, and you make it private and inaccessible, and then put a new interface around it, essentially entomb it in concrete so that no one can get close to it. In other words, if you can’t fix it, at least contain the damage, prevent it from spreading.<\/em><\/p>\n

Microsoft has taken another approach here. Instead of containment, they are propagating the bug even further. We need to think beyond Excel and think as well of other applications that work with OOXML data, and other applications that work with those apps and so on, the entire network of data dependencies. The mere existence of this bug in a standard will lead to buggy implementations, poor interoperability, and general chaos around dates. The fallout of this bug should have been contained within the source code of Excel. For this to leak out, into a specification, then a standard and then into other implementations, contradicting both the civil calendar and every other tool that deals with dates, will pollute the entire ecosystem.<\/p>\n

This is bad news. Just say no.<\/p>\n","protected":false},"excerpt":{"rendered":"

In 1994, the world learned that the Intel Pentium chip had a bug. In certain cases it gave the wrong answer when calculating floating-point division. These cases were rare, only 1 in 9 billion divisions, and typically only resulted in errors past the 8th decimal place. What did Intel do about this? Well, there was […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[6,198],"tags":[],"class_list":{"0":"post-36","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-ooxml","7":"category-popular","8":"entry"},"_links":{"self":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/36","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/comments?post=36"}],"version-history":[{"count":5,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/36\/revisions"}],"predecessor-version":[{"id":855,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/36\/revisions\/855"}],"wp:attachment":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/media?parent=36"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/categories?post=36"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/tags?post=36"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}