Microsoft and the Law of Inheritance of Anomalies

A few years back, the Computer of IEEE started with new staff of computer scientists and the first issue of the journal was filled with articles from well-established scientists. The one that I can recall for this writing was written by, N. Wirth the designer of Pascal programming language. One statement of the article was nicely decorated in the sidebar area. It said something like this: “There had not been so many defects in software until the graphic debugging facilities were invented”.

The implication is obvious. The question is, whether as much software was possible to write prior to the invention of modern debugging facilities? That article must have had the approval of referees, or at least the editor-in-chief. Evidently, they liked that statement so much that it had to be decorated so it would not be missed! After all, I still remember it.

During the time of Professor Wirth there were fewer software development shops, including his academic shop. Before that number could make a jump, modern software development facilities had to be invented. In addition, as tools and languages became better the size of programs increased exponentially. A lot of defects have nothing to do with debugging facilities because the facilities are not applicable (e.g. distributed software). Finally, a larger number of defects does not mean a higher ratio of defects relative to the number and the size of software.

The point of this article, however, is the Law of Inheritance of Anomalies. Consider using a class from a C++ third-party library. When calling some of the methods, you expect a certain member to be updated. It so happens that the member does not get updated consistently. Since C++ has no abstraction similar to class invariants of Z++, this type of inconsistencies is quite abundant in C++ software. Access to the entire library code does not make it feasible to fix the defect in the original code.

Under the above circumstances, one tries to guess via experimentation as to when the member does, and when it does not get updated. Based on that finding, the engineer will write code to work around the library defect. As it always happens, the inconsistency in the library code is actually random! Thus, the workaround does not work as expected, either. Now, your software has inherited the anomalies of the third party library, even with improved genes of your workarounds.

For Microsoft engineers, workaround is normal state of affairs. It all started with DOS, and ever since much of Microsoft’s work has been workarounds. Eventually the number of workarounds will exceed the size of crew that Microsoft is willing to have. Once this tipping point reaches, Microsoft will do the same to its shops as car companies did to their dealers. Perhaps Palm is a good case of abandoning an operating system that is plagued with inherited anomalies.

The context of this article is software. Nonetheless, one can see similar cases in politics. The anomalies planted by Reagan into our economy, as profitable as they were for his constituents, finally hurt millions that Reagan did not care about. In his words, “America is too big for small dreams”. The problem was that instead of removing the anomalies, they were inherited with workarounds, very much like what painkillers do, until they kill you altogether.

Reagan style of economic policy is a depressive form of communism in which the greater majority of the population lives at the mercy of a few that may find them useful for their profitability desires, what Reagan refers to as Big Dreams. The notion of communism is simply restricted to a much smaller elite group. This cannot possibly qualify as a definition of capitalism.

When the availability of jobs is primarily based on the profitability visions of uneducated rich, spending in education merely creates educated slaves. Reagan followers do not like the idea because it is hard to control educated slaves, as we saw in the last election.