Difference between revisions of "Complexity Oriented Programming"
| Line 51: | Line 51: | ||
In this case, we could imply that it is implied that ''complexity itself becomes the primary organizing variable for architecture, coordination, decomposition, and governance''. | In this case, we could imply that it is implied that ''complexity itself becomes the primary organizing variable for architecture, coordination, decomposition, and governance''. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=What it would draw from= | =What it would draw from= | ||
Revision as of 19:16, 23 May 2026
"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.
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.