Complexity Oriented Programming - Revision history

TiberiusB: /* Elements of Complexity Driven Development */

2026-06-17T05:32:03Z

Elements of Complexity Driven Development

TiberiusB: /* Key principles that could define it */

2026-06-17T05:26:03Z

Key principles that could define it

TiberiusB: /* Subject-Oriented Programming (SOP) vs Complexity-Oriented Programming (COP) */

2026-06-17T05:24:13Z

Subject-Oriented Programming (SOP) vs Complexity-Oriented Programming (COP)

TiberiusB: /* Elements of Complexity Driven Development */

2026-06-17T05:21:39Z

Elements of Complexity Driven Development

TiberiusB: /* Elements of Complexity Driven Development */

2026-06-17T05:17:27Z

Elements of Complexity Driven Development

TiberiusB at 05:03, 17 June 2026

2026-06-17T05:03:31Z

TiberiusB: /* What it would draw from */

2026-06-17T05:01:46Z

What it would draw from

TiberiusB: /* In essence */

2026-06-17T05:00:11Z

In essence

TiberiusB: /* Key principles that could define it */

2026-06-17T04:55:33Z

Key principles that could define it

TiberiusB: /* Computational model: from execution to coordination */

2026-06-17T04:52:25Z

Computational model: from execution to coordination

@@ Line 233: / Line 233: @@
 * '''Fractal composability''' - we can also find this at the development level, how teams or groups can assemble on tasks and how tasks are defined. Speaks to iterative work: design, prototype, test.
 * '''Stigmergy''' - mode of coordination between developers.
 =Where it already exists implicitly=

← Older revision		Revision as of 05:26, 17 June 2026
Line 203:		Line 203:

	'''Fractal composability is central''' because it supplies the structural principle missing from most existing paradigms. Most software architectures suffer from scale discontinuities at different levels: object, module, service, organization and ecosystem, because all use different coordination logics. ''Fractal composability'' proposes the same organizational principles repeat across scales. That means that individuals, teams, services, organizations, federations, ecosystems, can all be modeled using homologous structures. This is very unusual in software engineering. Conventional architectures are usually hierarchical, layered, non-recursive and scale-breaking. Fractal composability instead implies recursive governance, recursive coordination, recursive economic relations, recursive interfaces, recursive semantic structures. This resembles category-theoretic composability, cellular organization in biology, recursive institutions, holonic systems and viable systems theory.		'''Fractal composability is central''' because it supplies the structural principle missing from most existing paradigms. Most software architectures suffer from scale discontinuities at different levels: object, module, service, organization and ecosystem, because all use different coordination logics. ''Fractal composability'' proposes the same organizational principles repeat across scales. That means that individuals, teams, services, organizations, federations, ecosystems, can all be modeled using homologous structures. This is very unusual in software engineering. Conventional architectures are usually hierarchical, layered, non-recursive and scale-breaking. Fractal composability instead implies recursive governance, recursive coordination, recursive economic relations, recursive interfaces, recursive semantic structures. This resembles category-theoretic composability, cellular organization in biology, recursive institutions, holonic systems and viable systems theory.
		+
		+
		+	The honest challenge of COP is tooling. Debuggers, type systems, and unit tests all assume reducibility. COP requires new ''verification'' paradigms, closer to simulation and formal methods than conventional testing. This is reflected in the [[NDO]] testing strategy, which relies on multi-agent Tryorama scenarios rather than isolated unit tests.

	=Computational model: from execution to coordination=		=Computational model: from execution to coordination=

@@ Line 86: / Line 86: @@
 SOP and COP become surprisingly close when it comes to ''the role of composition''. SOP's key operation is '''compose subjects'''. COP's key operation is more like '''compose adaptive systems'''. Both reject monolithic structures. Both value modularity and multiple viewpoints, but they compose different things. SOP composes perspectives. COP composes complexity. Or more precisely:
   COP composes autonomous agents, processes, resources, constraints, governance structures, and knowledge flows into coherent adaptive systems.
 The notion of [[fractal composability]], as described here and on [[Sacha]]'s AlterNef, creates perhaps the clearest distinction. SOP does not fundamentally address scale. A subject exists at one modeling level. COP explicitly asks ''can the same coordination principles apply recursively across scales?'' For example '''Individual -> Team -> Project -> Organization -> Federation -> Ecosystem'''. This recursive concern is largely absent from SOP. COP therefore looks less like a descendant of OOP and more like a descendant of cybernetics, complex adaptive systems, viable systems theory, holonic systems and network organizational theory.

@@ Line 230: / Line 230: @@
 ==Elements of Complexity Driven Development==
 * '''Path Dependency Awareness''' - use AI to analyze the history of development of something, the choices that have been made, different exploration paths / attempts, success and failure, and produce a report on a regular basis, to reveal potential biases related to the history of work, to past choices. This is a feedback loop that informs better decision making.
-* '''Fractal composability'''
+* '''Fractal composability''' - we can also find this at the development level, how teams or groups can assemble on tasks and how tasks are defined. Speaks to iterative work: design, prototype, test.
 =Where it already exists implicitly=

@@ Line 230: / Line 230: @@
 ==Elements of Complexity Driven Development==
 * '''Path Dependency Awareness''' - use AI to analyze the history of development of something, the choices that have been made, different exploration paths / attempts, success and failure, and produce a report on a regular basis, to reveal potential biases related to the history of work, to past choices. This is a feedback loop that informs better decision making.
 =Where it already exists implicitly=

@@ Line 63: / Line 63: @@
 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==
@@ Line 167: / Line 218: @@
 This is a major conceptual leap. It resembles distributed systems, actor models, process calculi, biological systems, economic coordination systems, ecological systems. But COP generalizes beyond all of these.
 =Complexity Driven Development (CDD)=

← Older revision		Revision as of 05:01, 17 June 2026
Line 133:		Line 133:
	'''[[Complexity science]] applied to software engineering'''		'''[[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.
−	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.

@@ Line 149: / Line 149: @@
 ==In essence==
-Mainstream software engineering asks: “How do we reduce software complexity?”
+Mainstream software engineering asks: “''How do we reduce software complexity?''”
-COP/CDD asks: “How do we construct systems that remain coherent while complexity grows, evolves, differentiates, and reorganizes itself?”
+COP/CDD asks: “''How do we construct systems that remain coherent while complexity grows, evolves, differentiates, and reorganizes itself?''”
-This shifts the center of software engineering from: optimization, efficiency, control, determinism,
+This shifts the center of software engineering from: optimization, efficiency, control, determinism, toward adaptive organization, [[composability]], [[coordination]], [[emergence]], scalability of cognition and governance. The difference is comparable to '''classical mechanics → complex systems theory''', or '''centralized planning → self-organization''', or '''static architecture → living architecture'''.
 In mainstream engineering complexity is mostly local and syntactic.
-Toward adaptive organization, [[composability]], [[coordination]], [[emergence]], scalability of cognition and governance.
+In COP complexity becomes systemic and semantic. It includes various forms of complexity: organizational, coordination, economic, governance, cognitive, infrastructural, interoperability and temporal.
+So the “unit” of analysis is no longer merely: '''function → class → module'', but rather '''agent → process → relation → network → ecosystem''', a computational paradigm for organizing complex adaptive socio-technical systems. That is much broader than programming languages. It integrates systems theory, cybernetics, distributed cognition, network organization, peer production, composability, recursive, modularity, stigmergic coordination. This places it closer to Stafford Beer, Christopher Alexander, Herbert Simon, Elinor Ostrom and Niklas Luhmann, to complex adaptive systems theory, than to traditional software engineering.
 =Key principles that could define it=

@@ Line 205: / Line 205: @@
 =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.
@@ Line 211: / Line 210: @@
-'''Fractal composability is central''' because it supplies the structural principle missing from most existing paradigms. Most software architectures suffer from scale discontinuities:
+'''Fractal composability is central''' because it supplies the structural principle missing from most existing paradigms. Most software architectures suffer from scale discontinuities at different levels: object, module, service, organization and ecosystem, because all use different coordination logics. ''Fractal composability'' proposes the same organizational principles repeat across scales. That means that individuals, teams, services, organizations, federations, ecosystems, can all be modeled using homologous structures. This is very unusual in software engineering. Conventional architectures are usually hierarchical, layered, non-recursive and scale-breaking. Fractal composability instead implies recursive governance, recursive coordination, recursive economic relations, recursive interfaces, recursive semantic structures. This resembles category-theoretic composability, cellular organization in biology, recursive institutions, holonic systems and viable systems theory.
 =Computational model: from execution to coordination=

@@ Line 237: / Line 237: @@
 =Computational model: from execution to coordination=
-The OVN “computational model” material seems especially important. Traditional programming paradigms assume:
+From [[computational model]], traditional programming paradigms assume that a program executes, computation transforms data and control flow orchestrates operations. COP appears to redefine computation itself. Computation becomes:
 * coordination of distributed agency,
 * propagation of constraints,
@@ Line 249: / Line 244: @@
 * synchronization across heterogeneous contexts.
-So computation is no longer merely: input → algorithm → output
+So computation is no longer merely: '''input → algorithm → output''', but something more like: '''state of relations → interaction dynamics → emergent reorganization'''
-But COP generalizes beyond all of these.
+This is a major conceptual leap. It resembles distributed systems, actor models, process calculi, biological systems, economic coordination systems, ecological systems. But COP generalizes beyond all of these.
 ==Subject-Oriented Programming (SOP) vs Complexity-Oriented Programming (COP)==