“Emergence” is defined in terms that seem, at first, to dance around rhetorical redundancy.

Aristotle (384–322 BC) is recognized as the first to describe emergence :

On Aristotle’s view, human beings, like other “secondary” substances, arise from a distinctive 
arrangement of the four material elements. While the mental powers of human beings require and 
are necessitated by such an arrangement, these powers are distinct from, and downwardly causally 
efficacious with respect to, any non-mental powers.

Let's bring this wording forward about 2300 years. Consider a system composed of elemental parts. The elemental parts are considered to be well-known in their properties and interactions. As this system increases in complexity, there can be observed additional behaviors, which are unique and distinct from the total of the properties exhibited by the elemental components. Furthermore, the newly exhibited behaviour of this complex system cannot be explained through any logical examination of the component elements and their properties. The new behaviour has “emerged” from the complex system of elemental components.

Darwin used the idea of emergence to describe new behaviours of living beings that, although possibly explained by evolutionary incremental response to the being's external environment, nevertheless exhibited behaviour to adapt that could not have been predicted in any logical way from analysis of the preceeding environment and behaviours.

We technologists, especially of the software engineering kind, discuss emergence most often in context of SystemArchitecture (and EnterpriseArchitecture). Our systems are built of components, often independent services, which we have created to have very specific, Mathematically complete, API's. Functions of those API, their methods, which we call “behaviour”. This system grows in complexity as we add other component-service to it, accomplishing more and greater processes. At some point, as we continue to observe the operation of this system in real-time, we begin to observe interactions of the system with client-callers that are beyond the original definition of the system nor any of it's component-services. This behaviour has emerged by it's complex composition, exhibiting a behaviour that previously was not predicted. Most often, this new behaviour is often surprising and could not have been predicted by any logical analysis of the component-services and their API functions.

The code we write, within a single library or application, is a complex system of elemental components. In this context, the general limitation of the definition of “elemental” should be that of a simple function.

def add(x, y) { return x + y; }

When we write “code” it is common to start with the imperative, TopDownProgramming style. Step 1, Step 2, Step 3. “Lather. Rinse. Repeat.”. Instructions are not only concrete in the operation of our computers – Machine Language (“Assembly”). Instructions are ubiquitous within our society and culture.

So, we form the process of building an “idea” into code. Many steps at a time.

Many steps at a time. This is the critical part. A complex application, then, has a multitude of instructions – complex functions that perform many steps. Often these functions exhibit (or “perform”) more than one behaviour at a time. An “elemental” function as above, then, represents a function that exhibits exactly one behaviour. This is the basis of the SingleResponsibilityPrinciple.

Our complex application exhibits behaviours that are greater than the functions of which it is composed. These extended behaviours are our application's API.

What are the elemental functions though? We started writing this application with multi-step functions, steps to describe building our “ideas” from the nothingness of an empty environment.

Our complex application, as it continues to grow in complexity, also begins to cause pain to both users and developers. “Behaviours unexpected” begin to be exhibited as the user executes the application – BUGS!!! This state of the application is definitely exhibiting behaviours that could not be predicted!!

But wait… this is CODE! Mathematical! Cold, calculated, complete! How could we observe behaviours that cannot be predicted??

Come back to the construction of our application – multi-step functions. With an application of “sufficiently large size”, no human could be reasonably expected to be able to “memorize” the entire function set of the application. The minimum size for an “inscrutible” application is a lot smaller than anyone suspects. And this trick of complexity requires memory, which is often shorter than the time frame it takes to change or add functions to the system.

What do we do!? Refactoring!!

CleanCode version

MonkeysAtKeyboards

Embrace