A Theory of Evolution

Artificial science. Evolutionary software. Chess. AI. Brute force vs. selec­tive search. Probability theory vs. symbolic reasoning. Neural networks and Bayesian models. Much to digest, but they define the scientific under­pinnings of the information sector and the principles underlying all of the information products that are coming to govern our lives.

AI’s founders were amazingly insightful. Simon, Shannon, and McCarthy were all around during the earliest years of computing. Yet they not only saw that a computer could evolve beyond its limited role as a computational machine into a general intelligent aide, they also saw how to do it! By 1970, they and a small number of colleagues had out­lined virtually every important AI research topic. Their ability to recog­nize these challenges from the starting gate is truly impressive—though their consistent inability to appreciate the full complexity of the issues that they identified may be equally impressive. Their insights at the dawn of the computer age helped launch the information sector. Its growth since then has been mostly a matter of evolution, and the scientific study of that evolution has centered on AI. AI remains the area of computer science most interested in shifting challenging tasks from the human envi­ronment, across the interface, and into the computing environment. It also remains the only scientific field to actually boast about being “arti­ficial” in the sense that Simon first intended, and thus the one most rel­evant to the study of Simon’s artificial interface artifacts.

AI remains a multidisciplinary field, where psychologists, linguists, and management scientists mingle freely with mathematicians, statisticians, and electrical engineers. The first three groups study the human organ­isms and labor to understand the human environment; the last three serve the realm of the silicon-based voltage-reading creatures.

But evolution is science. And as everyone knows, science alone doesn’t put products on the shelves or equities in our portfolios. Academics of all stripes are notoriously poor product developers; they tend to get dis­tracted by interesting theoretical challenges and philosophical puzzles. Consumers, on the other hand, prefer things that actually work, that perform useful tasks, and in the case of software, that make their com­puting experiences faster, easier, more productive, and more enjoyable. This consumer preference helped to push many of AI’s evolutionary ideas out of the university and into the commercial world, where they landed in the lap of software developers and software companies.

The science that had motivated AI researchers thus plays itself out as software engineering. As always, this shift from science to engineering engenders a significant shift in emphasis. Whereas AI’s artificial scientists want to understand the mechanisms underlying software evolution, the practical engineers of software development are more concerned with harnessing those mechanisms. Good software engineers don’t worry about the comparative theoretical purity behind selective or brute-force searches, information-intensive databases or general principles of problem solving, mathematical probability theory or abstract symbol manipulation. They learn about all of these techniques, develop broad toolkits, and use whichever combination appears best suited to the task at hand. In other words, software engineers shifted from Simon’s focus on the study of design processes to the more mundane task of actual design. That shift simplified a huge number of complex scientific issues that turned out to be purely tangential to the task of evolutionary soft­ware design.

Software engineering has its own notables, though they tend to be more focused and pragmatic than are AI researchers. They also tend to work for companies devoted to product development rather than for uni­versities. Fred Brooks, for example, worked for IBM back in the days that Big Blue dominated the world of computing. He served as a project manager first for the IBM System/360 family of computers, and then for the massive OS/360 operating system. These were critical positions; IBM’s 360 family was one of the dominant mainframes from the 1960s into the 1980s. Brooks thus possessed ample experience managing large teams of both hardware engineers and computer programmers focused on meeting cutting-edge technological challenges. More to the point, though, Brooks had to figure out how to manage these teams. He began with a general knowledge of management techniques, but he soon real­ized that coordinating a software design team posed unique challenges. Fortunately, Brooks chose to share his lessons in a series of essays. Once again, the insights of a pioneer proved to be remarkable. The Mythical Man-Month may be the only computing book from the 1970s that soft­ware engineers continue to study; Brooks’s analysis holds up even as the world of software has changed around it.¹⁸ In fact, his twentieth­anniversary edition affirmed all of his basic messages and most of his subsidiary lessons.¹⁹

Some of Brooks’s revelations remain central to the information sector—and in particular to understanding the Microsoft trial. He explained that complex software has a lot in common with a large number of other products, and showed how to tweak some standard management models to accommodate software design. Two textbook design principles, modular design and cost/benefit analysis, explain all but the most technical aspects of software design. Suppose that some cre­ative software developer figures out the math necessary to translate a vague, qualitative task into formal computation.

This new application is, in some sense, dangling off the edge of the preexisting frontier—perhaps communicating directly with users, perhaps allowing other programs to build upon it to dangle off the fron­tier still further, and perhaps both. This location presents some advan­tages and some disadvantages—in other words, it sets up a cost/benefit analysis. Perhaps the greatest benefit of having things dangling off the edge of the frontier is that they are easy to fix. If someone discovers a bug in the application or devises some clever way to improve it, he can snap the application off the frontier, modify it, and reconnect it without disturbing any of the translators between the hardware and the platform. Applications treated as experimental modules need not interfere with the smooth workings of either the platform or of the many translations beneath it.

These simple principles of cost/benefit analysis and modular design are among the keys to software engineering. They were prominent in Brooks’s work, we’ve been teaching them in elementary programming classes for decades, and they retain their importance at the highest levels of commercial development.

But modularity can also have a downside—particularly in terms of applications sitting on top of platforms. The downward translation sequence is time-consuming and a drain on the computer’s resources. Every additional translation layer reduces the efficiency of the comput­ing and slows things down—a concern that may have been much more important in the early days of computing than it is today, but one that still remains relevant. Extra translation layers also introduce seams into the system—and seams are where any product’s problems are most likely to occur. Simon’s interface artifacts raise their heads yet again. The natural science internal to the application must pass through the artifi­cial science at the seam into the natural science internal to the platform, and vice versa. The very description of the process suggests potential instability. If, instead, the platform could evolve to subsume the appli­cation, then coordination, stability, and efficiency might all be improved.

So much for Simon and science. Back in Brooks’s world of practical software engineering, “integration” forms the flip side of modularity. If the developer could integrate the application into the platform, the com­bined product might run faster and more fluidly.

Virtually all engineers face these sorts of trade-offs, and while they may disagree about the specific point at which to integrate an applica­tion into a platform, the general principle is well understood. Develop­ers should launch their new innovations as modular applications; new applications tend to contain large numbers of bugs, and modules are easy to fix and to improve. Beyond bugs, though, new applications—and in particular, powerful important applications—tend to motivate waves of innovation. Second- and third-generation releases typically embody not only fixes, but also new features, including some that the developers hadn’t even imagined at the time of their first release. Premature inte­gration can do more than simply complicate bug fixes; it can make it harder for developers to grasp the full potential of their products and to develop new and innovative features.

After a while, though, every application’s functionality tends to stabi­lize. Fixes and improvements become much less frequent, innovative fea­tures become few and far between, and efficiency concerns loom larger. Such an application is ripe for integration into the platform from a software-engineering perspective. While other factors may argue in favor of maintaining the application as a stand-alone module, the dual fears of causing collateral damage to a stable platform and of impeding inno­vative improvements shouldn’t apply to mature applications. Software engineers may well decide that the potential improvements to the appli­cation’s efficiency outweigh both the effort of integration and the po­tential decreases in the platform’s efficiency (after all, the larger the platform, the less efficient it is). They may decide to integrate the appli­cation’s functionality into the platform—thereby evolving the platform further from the machine and closer to humans.

This integration, of course, saves only a single translation. As the erst­while application’s functionality becomes increasingly robust, computer engineers may decide to migrate it even further downward—into machine language, and possibly even into the hardware, where much of Deep Blue’s intelligence resides. With each migration downward the effi­ciency of the application’s functionality may increase, but the complex­ity, cost, and systemic disruption of an upgrade will certainly skyrocket. While good software engineers may debate whether or not a specific application warrants the trade-off, the underlying principle of modular design remains as it was even before Brooks articulated it.