Making the Wrong Things Easy
In 1975, computer scientist Niklaus Wirth famously stated that "Algorithms + Data Structures = Programs" (the title of his book, which is still considered part of developer canon). Prior to the May 1991 release of VB 1.0, application development typically began with coding the program's algorithms and connecting them to data sources; the developer concluded by wrapping a user interface around the resulting application engine. Making algorithms correct and efficient and making data access robust and secure were visible and critical elements of the development process.In the process, features with substantial and dangerous power were unleashed without safety mechanisms. Subsequent versions of VB, for example, introduced facilities for writing "mail-enabled" applications that could generate and send e-mail messages without the user's intervention-or knowledge. During an early demo of VB's mail-enabling features, product testers at what was then PC Week Labs (now eWEEK Labs) asked if the Windows environment itself gave the user a top-level control-tower view-not to mention a master on-off switch-for actions such as sending out an e-mail, hands-free. The response from Microsoft's representatives was, essentially, "No. Why?" As it turned out, there were excellent reasons why safety mechanisms of this kind would have been a good idea. For Microsoft, 1999 may have ended with a whimper, as the government's protracted antitrust suit against the company produced no significant results, but it began with a bang in the form of the Melissa worm in the month of March. Melissa's victims ruefully discovered it was not only the independent VB developers who had access to e-mail channels and other top-level interfaces. Using the extensive automation facilities of Microsoft's Office applications, the simple but effective Melissa malware spread itself by means of e- mail. Another notable behavior of Melissa was that it used a standard Office API to disable the security warnings of macro execution. The fact that Melissa could do these things says a lot about the developer-centric thinking that often seems to have shaped Microsoft's technology model. As this writer noted at the time:
VB turned that process around: It encouraged the developer to begin by storyboarding the user experience, then going behind the curtain to define the results of the user's points and clicks. As soon as the program looked good and handled expected input correctly, there was a powerful temptation to declare victory and move on.
Bill Gates told us what he had in mind, 11 years ago, in a Byte magazine article entitled "Beyond Macro Programming." In his own words, recalling that article in a March 1998 retrospective, he "called for the creation of object models that would enable developers to control all the elements of an application, providing full application programmability." ... [Microsoft] Office dissolves the boundary between operating system and application, and even between application and data: An Office document can retrieve data from remote sources, manipulate data with external code and even manipulate other applications with no intentional action by a reader (who may have no idea that these actions are taking place). ... Windows begins with the model of a single user on a single, personally controlled machine, and never recovers from the resulting assumption that no piece of code would be on a machine if the user didn't want it to be there.As Microsoft continued to move forward into the era of ubiquitous, always-on connection, its heritage of single-system thinking-and Bill Gates' eagerness to make things possible, often before figuring out how to make them safe-would continue to afflict the company and its customers.