Emergence and Engineering

Introduction

The relationship of emergence and engineering is paradox. Emergence is the essence of computer science and IT, since it all emerges from binary digits, 0 and 1, and yet it is barely used in programming and software engineering. Although essentially all software is emergent, the concept of emergence is traditionally avoided in software engineering and computer science. There are only a few applications which are based on emergence among autonomous entities. Why?

The situation

The apparent lack of any computational system based on autonomous entities results partially from our limited ability to comprehend complex systems, and from our fear that these systems get out of control. Emergent properties can be found in computer science, but only at the edge in the following subfields: Multi-agent systems, complex systems, distributed systems, distributed artificial intelligence, artificial life, .. Our inability to handle complex systems with multiple interacting autonomous actors has lead us to consider only a narrow fraction of all possible systems. Modern computers are essentially very primitive machines. In every computer there is a single CPU which processes information serially, based on the simple Von Neumann architecture. As the brain or the internet shows, multiple nodes which interact which each other in real time can be much more powerful, but they are also much more difficult to construct and to understand, especially with our limited mathematical tools.

Computers are not that sophisticated, and they do not use autonomous entities in any form. If something is based on emergence in computer science, it is often not mentioned directly, because it is mainly an intended and “nominal emergence”. The only thing which emerges is the purpose of the machine or the function of the program. Other unexpected properties and unintended behaviors are nearly always bugs, faults or failures. Engineers have a top-down view, they prefer to speak in terms of code, information, and implementation instead of emergence and supervenience.

The blind spot of the engineers is their top-down focus. Outgoing from the function and the specification of the system, they try to construct the implementation. Engineers know the only thing which can emerge is the one they implement. This can be a feature if it is done right, or a bug if it is done wrong. The blind spot in the eye is the point where we can not see, because our view and our optical nerve originates here. The view of the engineer always originates from the function of the application. What is the function and the purpose of the application? How can we achieve it? The blind spot of the engineer is that there a systems where patterns emerge which have may have no function at all. An engineer does not how to handle such a system.

In his paper The reductionist blind spot, Russ Abbott has emphasized that the “reductionist blind spot” is a problem in general. According to Abbott, the reductionist blind spot is to neglect levels of abstractions by reducing everything to the elements. These levels of abstractions are entities of their own. Software engineers are very aware of different levels of abstraction. If they program in Ruby, they know Ruby is written C, and C in Assembler, and Assembler in Machine Code, and in the end everything they write is translated into Machine code. Yet they do not have to bother about the details of Machine Code for different processors, because the compilers and interpreters already do it for them. They have internalized that a low level implements a higher level of abstraction, and they operate mostly on the highest possible level of abstraction to make their work as easy as possible.

While the blind spot of the reductionist is that there are higher levels at all, the blind spot of the enigneers is that the lower level not only implements the higher level, but the higher level also emerges from the bottom, and this pattern is only a tiny fraction of all patterns which can emerge if we allow more freedom and autonomy. The neglected bottom-up view that emergent properties emerge from the lower level is traditionally suppressed because it is too difficult, and diametrically opposed to the function-oriented view of engineering. Yet emergence and implementation can be considered as two sides of a coin, a flock emerges from a number of boids, but the boids also implement a “flock”, etc. Emergent properties can be described as a high level abstraction which is implemented by low level elements.

The problem

Another aspect of the blind spot is that in the software world there are no mysteries. Christos Papadimitriou, CS Professor at UC Berkeley says in this Dr.Dobbs interview

“In computer science, we don’t have great mysteries.
We want to solve problems, but it’s not like we have
mysterious objects we don’t understand. It’s not like
Physics, which has the Universe, or Economics, which
has the Markets, Neuroscience has the Brain, and
Biology the Cell. For us, the computer and its software
are huge, complex, powerful, and fascinating, but we
constructed them. Intrinsically, there’s very little
mystery.”
~ Christos Papadimitriou

There are no mysteries, because we do not allow them. A system which is not understandable is unmanageable. The price for the manageability is that our systems are primitive and a bit boring. In systems with emergent properties, it is exactly this “mystery” aspect which makes the system interesting. The unpredictability of emergent properties is fascinating for scientists who want to explain a system but frustrating for engineers who want to control it. The basic problem is not only the reductionist blind spot, but also the inherent difficulties in combining autonomy and application.

Self-organization and emergence can be fascinating and frustrating at the same time. Impressive emergent properties are rare, complex patterns which result from very simple rules are rather the exception than the rule. This rarity makes them fascinating for scientists, but frustrating for engineers. Self-organization and emergence can be fascinating if we can observe wonderful patterns in simulations, frustrating if we have to find a function or purpose for them. They can be fascinating if something organizes and designs itself, frustrating if this organization and design does not fit our plans.

In general it is hard to reconcile organization, construction and design on the one hand with self-organization, emergence and autonomy on the other hand. There are two fundamental core problems, one basic contradiction on the level of the system (do we organize it, or can it organize itself?), and one basic contradiction on the level of the individual (does it what we want, or is it autonomous?).

The fundamental ESOA problem of engineering self-organizing systems or applications is to combine outside organization and self-organization, or engineering and emergence. Either a system organizes itself, or it is organized by us. How do I organize something which may organize itself? It is similar to the classic problem which dictators and despots like Gaddafi face: “the people should organize themselves, but I want to say how”.

The AOSE problem of agent-oriented software engineering is to combine autonomy and application. Either a system is autonomous, or it has a function. How do we control something, if it is autonomous and has an own will? How can we guarantee that a system with “free will” does what we want? The solution to both problems can be found in a trade-off: give up some control, grant more autonomy and let the system run, but impose some rigid constraints, basic rules and fundamental directives during a well-defined iterated process.

The solution

A possible solution to the ESOA problem is the application of the scientific method by the engineer, the step-by-step investigation of hypotheses with experiments and simulations to “find out the rules of the game”. The scientific method is an iterative process that is the basis for any scientific inquiry, and it can also be used to examine artificial systems and simulated worlds (for instance synthetic societies of multi-agent systems). The scientific method follows a series of steps: (1) identify a problem you would like to solve, (2) formulate a hypothesis, (3) test the hypothesis, (4) collect and analyze the data, (5) make conclusions and restart with (1) (see also the paper preprint On Engineering and Emergence).

The solution to the AOSE problem is to give the autonomous actors directives (in different degrees), like the directives of the robots in the film Wall-E. Wall-E has the prime directive to collect garbage, while EVE has the prime directive to search for organic life. Even the names mirror their purpose specified by the prime directive, the acronym Wall-E stands for small Waste Allocation Load Lifter – Earth Class, while EVE is the abbreviation of Extraterrestrial Vegetation Evaluator. As long as the autonomous entities follow these prime directives similar to Assimov’s classic laws of robotics, they are free to do what they want. The directives are a trade-off between the interests of the agent and the interests of the engineer, similar to the trade-off realized by a binding contract between employee and employer. These directives and guidelines can occur in different degrees, according to the standard subsumption architecture from Rodney Brooks. It is similar to the proof and verification of distributed algorithms: the prime directive guarantees the safety of the system, while the agility and curiosity of the actors granted by the autonomy must guarantee the liveness.

That means we must give up a bit of our total control and do not micro-manage machines and software in detail. We gain a much richer variety of behavior in return. As Kevin Kelly argued in his book “Out of control”, we can and should relinquish some of our total control. If we grant more freedom and autonomy for the system, then we lose a bit of control, but we gain a more powerful system.

Traditional programming and software engineering will not allow this modern approach based on emergence. Distributed systems are an exception. The web itself in fact emerged from millions of interacting nodes, and the PageRank (c) also emerges from the millions of links from one page to another.

Christos Papadimitriou says in the Dr.Dobbs interview about the web:

“In many ways, the Internet and the Web, we did not
create them. They arrived, appeared, emerged. All
these other artifacts, software, processers, and so
forth, there was a designer, a team, an entity that
intentionally built them. The Web emerged from an
interaction of millions of entities on the basis
of deliberately simple protocols. Thus the Internet
and the Web are our mysterious objects. Computer
scientists are looking at them the way other
scientists are looking at their mysterious objects. We
have to look at them using the scientific method:
observations, measurement, experiments, verifiable
theories, applied mathematics.”
~ Christos Papadimitriou

Conclusion

The resolution of the paradox mentioned in the introduction is the recognition that essentially all software is emergent; not none. Out computers so far only used the most simple forms. As Russ Abbott has pointed out, computer scientists and engineers have a certain reductionist blind spot and tend to ignore this fact. If we look beyond that blind spot, we can discover all kinds of interesting patterns and phenomena. We have outlined solutions for the core problems of combining emergence and engineering.

(The picture from EVE, the Extraterrestrial Vegetation Evaluator robot, is a low resolution screenshot from the highly recommendable Pixar film WALL-E)