Complexity Oriented Programming

"Complexity Oriented Programming" doesn't exist as a formal paradigm yet, which makes it worth thinking through carefully. Here's how I'd frame it:

The core intuition

Most paradigms are reduction strategies. OOP (object oriented programming) encapsulates. FP (functional programming) eliminates side effects. Procedural linearizes. They all try to make complexity disappear through abstraction. Complexity Oriented Programming (COP) would invert this: instead of hiding complexity, it would model it faithfully and work with it as the primary material.

To give full credit here, this explicit framing of p2p as complexity economics was sparked by Guillaume Rouyer during a discussion with Tibi, before the summer of 2025, when he introduced Edgar Morin (La Methode). After reading Morin things started to come together. Our use of bio-mimicry in the OVN model from the early days, the use of terms like stigmergy, self-organization, etc. were useful frames. Now complexity becomes THE framework. Note that Holochain uses the same type of terminology / metaphores: DNA, zomes, cells, ... Sensorica chose Holochain and not blockchain precisely because it allowed us to build "organic" infrastructures for OVNs. Now we see Holochain as a beginning of what we call Complexity Oriented Programming, a concept that will certainly evolve in the future.

A complex world runs on a complexity economy, which runs on a complexity infrastructure, which relies on generative grammars. Arthur Brock was talking about language in some of his presentations... Complexity Oriented Programming doesn't try to reduce complexity, to help us manage complexity, as some wrongfully describe it. We need to reclaime this expression! It allows us to embrace complexity. Computer programs need to be designed not as mechanical, linear, finite, but as generative of infinite states, as generative of attractors of behavior. They don't need to control or to predict. They don't need to precisely model. They need to allow humans to iterate and adjust.

Complexity cannot be understood, analyzed, controlled or predicted. It can be experienced and ridden like we ride a bicycle or serf a wave.

Yes, there are deterministic processes, causes and effects, at some levels of our economy or socia interactions, that part will be taken care of by state machines. The unpredictable and uncontrollable will be taken care of by complexity programming.

That's in short our initial thoughts... still half baked.

This is, according to us, the new tech paradigm that we need in order to support complex socio-economic processes. That is what we need to build new institutions for a increasingly complex world.

And all that rests on a new way of knowing, a new epistemology, the epistemology of complexity proposed by Morin. Full circle. Full stop.

Current traces of this concept

There are currently no established software engineering methodology or recognized programming paradigm widely known as “Complexity Oriented Programming” (COP) or “Complexity Driven Development” (CDD) outside the Sensorica / OVN context. In that regard, this seems to be emerging within the Sensorica OVN.

There is a broader ecosystem of adjacent approaches that treat complexity as the central design constraint in software systems.

Complexity as the central software problem

A major intellectual lineage in software engineering explicitly frames complexity as the root problem of software systems. One of the strongest examples is the paper Out of the Tar Pit by Ben Moseley and Peter Marks. It argues that most software failures originate from uncontrolled complexity, especially state management and control flow. Similarly, John Ousterhout’s work in A Philosophy of Software Design defines software quality largely in terms of reducing dependencies, obscurity, and cognitive load. But these authors do not propose a new paradigm named after complexity itself. Conceptually, this would mean:

• programming organized around complexity management,
• minimizing coupling,
• controlling emergence,
• maintaining comprehensibility under scaling.

This is contrary to what we mean, i.e. programming or development that embraces complexity.

Existing “X-Driven Development” families

The phrase “Complexity Driven Development” fits structurally into an already existing family of methodologies:

• Feature-Driven Development (FDD)
• Behavior-Driven Development (BDD)
• Model-Driven Engineering (MDE)
• Spec-Driven Development (recent AI-assisted workflows)

These approaches differ by what becomes the primary organizing abstraction: features, behaviors, models, specifications, etc.

In this case, we could imply that it is implied that complexity itself becomes the primary organizing variable for architecture, coordination, decomposition, and governance.

Complexity metrics and code maintainability

Another large field studies complexity quantitatively rather than philosophically. Typical examples:

• cyclomatic complexity,
• cognitive complexity,
• coupling metrics,
• cohesion metrics,
• dependency graphs.

These approaches attempt to measure complexity rather than define a new development paradigm.

This is relevant because our framing could potentially unify structural complexity, organizational complexity, coordination complexity, economic complexity, governance complexity.

Most existing engineering approaches isolate these dimensions instead of integrating them.

Distributed systems and “complexity-aware” abstractions

Some newer paradigms implicitly address complexity-heavy domains:

• cloud-oriented languages like Winglang,
• multi-agent programming,
• model-driven engineering,
• reactive systems,
• actor models,
• orchestration frameworks,
• event-driven architectures.

These approaches recognize that distributed systems create:

• emergent behavior,
• coordination overhead,
• asynchronous uncertainty,
• scaling problems,
• failure propagation.

But again, they usually frame themselves around: distribution, agents, cloud infrastructure, models, rather than complexity itself.

Our terminology is distinctive

The interesting thing is that our formulation is broader than conventional software engineering. “Complexity Oriented Programming” could mean:

• architecture shaped by complexity gradients,
• adaptive composition / decomposition,
• governance-aware software structures,
• socio-technical co-design,
• stigmergic coordination,
• dynamic modularity,
• resilience under emergence,
• evolutionary organizational architectures.

That moves beyond ordinary software paradigms and toward:

• cybernetics,
• systems theory,
• network organizational theory,
• distributed governance,
• coordination science.

In that sense, our framing resembles:

• Christopher Alexander’s pattern language,
• Stafford Beer’s cybernetics,
• complex adaptive systems theory,
• distributed cognition,
• peer-production systems,

actually more than conventional programming methodology.

What it would draw from

Complexity science offers a clear vocabulary: emergence, feedback loops, attractors, phase transitions, edge of chaos, adaptive agents. COP would translate these into first-class programming concepts. You wouldn't fight emergence, you'd design for it. You wouldn't isolate components from their environment, you'd model the coupling.

Complexity science applied to software engineering

There is a substantial body of work applying complexity theory and systems thinking to software projects and organizations. Examples include:

• complex adaptive systems,
• socio-technical systems,
• systems engineering,
• cybernetics,
• project complexity management,
• distributed coordination theory.

For example, PMI’s work on project complexity explicitly discusses non-linearity, feedback loops, emergence, adaptive management, dynamic organizational behavior.

This literature is organizational and managerial more than programming-language-oriented, but it aligns strongly with our direction.

Key principles that could define it

Rather than single sources of truth, you'd have distributed state with coherence protocols. Rather than deterministic pipelines, you'd have adaptive feedback architectures. Side effects wouldn't be contained, they'd be typed as relational events flowing through a graph. Time and context would be primary, not afterthoughts.

Where it already exists implicitly

Some things already approximate COP without naming it:

• Holochain's agent-centric model, where global coherence emerges from local validation rules and the NDO hApp.
• Reactive/dataflow systems (signals, FRP)
• Actor model concurrency
• Cellular automata as computational substrate
• Valueflows/REA, which models economic reality as flowing events rather than static entities

The epistemological shift

In classical paradigms, the programmer is a god who designs a closed system. In COP, the programmer is more like an ecologist who designs conditions for emergence. You write rules, thresholds, feedback sensitivity, and then you observe what arises. The system is never fully knowable from the source code alone.

The honest tension

The hard challenge is tooling. Debuggers, type systems, tests, all assume reducibility. COP would need new verification paradigms, probably closer to simulation and formal methods than unit tests.

Given your work on NDO and the recognition architecture framework, there's a strong argument that what Sensorica is building is COP in practice: protocol-level rules that produce economic coordination as emergent behavior, without a central orchestrator. The Valueflows ontology isn't modeling a machine, it's modeling a living economic ecosystem.

See also

• Complexity economics