26 CHAPTER 1 Systems supervise five to ten vice presidents. The same thinking applies to armies. Even layers can be thought of as a kind of degenerate one-dimensional hierarchy. There are many other striking examples of hierarchy, ranging from microscopic biological systems to the assembly of Alexander's empire. A classic paper by Herbert Simon, "The architecture of complexity" [Suggestions for Further Reading 1.4.3], con- tains an amazing range of such examples and offers compelling arguments that, under evolution, hierarchical designs have a better chance of survival. The reason is that hierarchy constrains interactions by permitting them only among the components of a subsystem. Hierarchy constrains a system of N components, which in the worst case might exhibit N 3 (N 2 1) interactions, so that each component can interact only with members of its own subsystem, except for an interface component that also interacts with other members of the subsystem at the next higher level of hierarchy. (The interface component in a corporation is called a "manager"; in an army it is called the "commanding officer"; for a program it is called the "application programming interface".) If subsystems have a limit of, say, 10 components, this number remains constant no matter how large the system grows. There will be N/10 lowest level sub- systems, N/100 next higher level subsystems, and so on, but the total number of sub- systems, and thus the number of interactions, remains proportional to N. Analogous to the way that modularity reduces the effort of debugging, hierarchy reduces the number of potential interactions among modules from square-law to linear. This effect is most strongly noticed by the designer of an individual module. If there are no constraints, each module should in principle be prepared to interact with every other module of the system. The advantage of a hierarchy is that the module designer can focus just on interactions with the interfaces of other members of its immediate subsystem. 1.3.5 Putting it Back together: Names Make Connections The four techniques for coping with complexity--modularity, abstraction, layering, and hierarchy--provide ways of dividing things up and placing the resulting mod- ules in suitable relation one to another. However, we still need a way of connecting those modules. In digital systems, the primary connection method is that one module names another module that it intends to use. Names allow postponing of decisions, easy replacement of one module with a better one, and sharing of modules. Software uses names in an obvious way. Less obviously, hardware modules connected to a bus also use names for interconnection--addresses, including bus addresses, are a kind of name. Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. -- Douglas Hofstadter: Gödel, Escher, Bach: An Eternal Golden Braid (1979)