Skip to Main Menu

The guessing game of abstractions

My last blog entry on difficulties in abstractions has been summarized nicely by Jessica Kerr in her tweet

“To find the right abstraction, guess.If it exhibits the right properties, stop.”

With that theme I’m going to dive into the guessing game of abstraction in this blog post.

Reductionism vs emergent behavior

Consider a vehicle which can turn. Something similar to picture below:

Turning Bus

The parts that moves the bus are tyres. Each individual tyre can only move forward or backward. So how does the bus takes a turn? If you observe the arrangement of tyres, the front tyres are arranged at a particular angle. So the circular movement of the bus can not be found in individual tyres, but how these tyres are arranged.

Let’s assume for a moment that the tires are not visible to you and you have to model this behavior. The reductionist approach will lead to finding an abstraction which mimicS the behavior found in bus to its components. So each tyre on the bus needs to rotate around itself. It will be somewhat a spherical ball tyre. But as you can see it is quite far away from the actual picture you see on the bus. So we are missing something.

A different idea coming from complex systems science is that properties of a system could also be due to interactions between it’s components or particular arrangements of components. This is known as emergence. This is in contrast to reductionist approach which entails attributing properties of the system to properties of one of it’s parts. Reductionist approach, focuses only on components of the system ignoring the interactions, and emergence approach considers relationship between components as well. P.W. Anderson has written a wonderful article on this if you want to go into details of this.

As I had described in my abstractions blog post, abstractions always come in twos hence one will need to be aware of limits of reductionist approach and will need to consider implications of emergence.

Remember lock is a lock because of the key or more succinct example would be air pressure of a gas is due to collisions in the constituent molecules/atoms. Understanding of techniques to model behavior of the collective will be a good tool to have in one’s repertoire. In the next section I will introduce some techniques I found useful.

Complexity Profile

Modeling collective behavior can be best understood by a concept called complexity profile. Dr. Yaneer Bar Yam has covered it so well that all I have to do is to quote snippets from his paper Complexity Rising to make the point.

Why is complexity profile useful

A more systematic way of thinking about the problem of understanding collective behavior
uses the concept of a complexity profile. The complexity profile focuses attention on the
scale at which a certain behavior of a system is visible to an observer, or the extent of the
impact it can have on its environment. Both of these are relevant to interactions of a system
with its environment—an observer can see the behavior only when the behavior is sufficiently
large to affect the observer.

What is scale in complexity profile

A formal definition of scale considers the spatial extent, time duration, momentum and energy
of a behavior. More intuitively, when many parts of a system act together to make a single
behavior happen, the behavior is a large scale one. When only a few parts of a system act
together, the behavior is a small scale one. The energy of different actions of the system is
also relevant. When the amount of energy devoted to an action is large, then it is a large scale
action. In essence, the units of energy are working together to make a large scale behavior.

Definition of complexity profile

The complexity profile counts the number of independent behaviors that are visible at a
particular scale. The use of the term "complexity" reflects a quantitative theory of the degree
of difficulty of describing a system's behavior. In its most basic form, this theory simply
counts the number of independent behaviors as a measure of the complexity of a system. The
complexity profile characterizes the system behavior by describing the complexity as a
function of scale. Intuitively, we are considering a system described at different levels of
detail. The complexity profile tells us how much information is needed to describe a system
at each level of detail.

Camera zoom as an analogy for complexity profile

The zoom lens on a camera seems to capture this idea because zooming in provides more and
more detail. The problem is that as we zoom in we see less and less of the entire system. To
be consistent about what we are describing we must always describe the entire system no
matter how detailed our description becomes. Thus, it is better to think about focusing the
camera more and more accurately. Changing scale is changing the precision of observation, not
changing the system that we are observing. This means that as we increase the level of
precision we also increase the length of our description.

The central point of complexity profile

When the behaviors of parts are coupled in subgroups, their behavior manifests at the scale
corresponding to the size of the group. The central point is: When the independence of the
parts is reduced, the scale of behavior is increased. This also means that describing the
behavior of the parts is simpler because they are doing the same thing.

The central point is: When the independence of the parts is reduced, the scale of behavior is increased.

Complexity profile facilitates trade-off

This means there is a trade-off between the length of our description of a system at large
scale, and the length of the description at fine scale. If we consider various systems that might
be made of the same materials (and with the same energy), we can use the complexity profile
to compare them. Each way of organizing the system (and distributing the energy) results in
tradeoffs between the complexity of their microscopic description against the complexity of
their description at progressively larger scales.

Independent vs Coherent behaviour

Independent behavior is to be contrasted with coherent motion. In coherent motion all of the
parts of the system move in the same direction. This is the largest scale behavior possible for
the system. Since the behaviors of the parts of the system are all the same, they are simple to
describe on the largest scale. 

Complex system is a combination of independent and coherent behavior

Neither of these two examples corresponds to complex collective behavior, for example a
human being. Unlike the coherent motion case, the complex behavior of a human being must
include many different behaviors. Unlike the independent action case, many of these
behaviors are visible on a large scale. In order for such visibility to occur various subgroups of
the system must have coordinated behaviors. The resulting correlations are distributed at
different scales. Some of them are found at a microscopic scale in the coupled motion or
positions of molecules, and others appear in the collective motion of, for example, muscle
cells and the motion of the body as a whole. Thus, the complexity profile of a complex
system like a human being involves a distribution of scales at which behavior manifests itself.
This balance between highly random and highly ordered motion is characteristic of the
behavior of complex systems.

With basic concepts of complexity profile enumerated above, we can now apply this to the bus tyre example.

Complexity profile analysis of bus moving

Movement of the bus is the behavior of the collective. All tyres and their co-ordinators must participate to make the movement possible. Each tyre can move independently without any coordination but that will take the bus apart. Also each individual tyre is not capable of moving the entire bus. So now get into trade offs. If we want an independent behavior of the tyre, it will be a unityre bus. So far I’ve not seen any bus like that. So at the scale of a bus, we have to subordinate the movement of the tyres to a control system which will govern speed and direction of each tyre. The control system is an orchestrator.

Now there could be one or many orchestrator adding different movement capabilities to bus. Here again the scale comes into play. If we have 3 orchestrators,one each for front and back tyres and one orchestrator to control 2 orchestrator, front and back tyres may be moving independent of each other and yet their movement is coordinated. But again there is a tradeoff. If you have observed drag racing cars, they achieve speed by curtailing the movement of the tires and their control system. The drag racing cars can move only in straight line. They replace multiple orchestrators with a single one. Scale at higher level means simplicity at component level.

Now consider the 3 orchestrator scenario again. If each orchestrator controlling tyre movement has sensors to track the speed, it can form a closed feedback loop system in itself. So given a speed setting given by higher level orchestrator, the tyre orchestrator will compensate for external conditions and maintain the set speed. So tyre orchestrator can act independently and react to external environment while still subordinating some of its behavior to coordinator of the system. The effect here is reverse. By adding complexity at component level, we have simplified behaviour at system level.

Heuristics about nature of components

The important idea that I learnt from complexity profile ideas is to observe and guess the scale of the component and then apply the idiom: If scale is large, components will need to be simple. If the system has number of independent behaviors, the scale would be small and components complex. As we have two contrasting ideas, we can start calibrating our system between these two ideas to achieve the necessary design that will satisfy given requirement.

Most often the problem of identifying responsibility is due to the effect of multiple entities of the same type collaborating to produce the required effect. It becomes very difficult to identify which is the property of the component and which is due to collective. So we need model interaction as a first class concept itself. For that I want to highlight the role of orchestrator in above example. Orchestration as a first class concept is somewhat of an anathema in current developer community. As Greg Young expressed in his talk a decade of DDD, processor manager will play an important role in upcoming development paradigms.

I leave you with a quote from Donald Reinertsen, “The value of any system is in the connection between the components. The connections add value but they also add complexity.”

comments powered by Disqus