Decoding Software Complexity: Classic Definitions and Three Analytical Dimensions

Survey of Software Complexity Definitions

The article opens by referencing a discussion about an AI-related claim—specifically, that protein structure prediction itself is not complex (it was an efficiency problem), whereas inventing AlphaFold was a genuinely complex endeavor, as detailed in Demis Hassabis's autobiography.

Classic Definitions of Complexity

John Ousterhout — A Philosophy of Software Design

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

Herbert Simon — The Architecture of Complexity

Simon argues that the defining property of complex systems is hierarchy (degree of hierarchy) and near-decomposability . A complex system is composed of subsystems, which in turn contain sub-subsystems, and so on. Software systems are built by composing structures at different hierarchical levels.

Melanie Mitchell — Complexity (Thermodynamic Depth)

Mitchell defines complexity by identifying the most scientifically plausible sequence of events that produced the artifact, then measuring the total thermodynamic and informational resources required. For software, Git commit history might offer a trace of this constructive process.

John Gall — Systemantics (1975)

A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.

Nassim Taleb — The Black Swan (Functional Definition)

Taleb describes complex domains as having high interdependence among components: temporal dependence (a variable depends on its past), horizontal dependence (variables depend on each other), and diagonal dependence (variable A depends on the history of variable B). This interdependence creates positive feedback loops, fat tails, and nonlinearity, preventing the Central Limit Theorem from applying.

Larry Tesler — Tesler's Law (Conservation of Complexity)

Proposed in 1984: every application contains an irreducible amount of inherent complexity. The key question is not whether to eliminate it, but who bears it—the developers (and underlying hardware/algorithms) or the users.

Bill Gurley — Multivariable Nonlinear Systems

I would describe complex systems as multivariable nonlinear systems. And multivariable nonlinear systems are very hard to predict. They can behave one way for a long time, and then one variable can switch and they can behave another way—the weather, stock markets, all these things. There are consequences that can be first, second, or third-order. You can't just think with a linear model or just think about one variable because things can go way off the path. You need to be aware that if you make a change here, it could change something here, which could change something there, and it has to be the whole system. You've got to be really conscious of the consequence and not get too deterministic about a single metric or a single variable.

Stephen Wolfram — Computational Irreducibility

Wolfram defines complex systems by computational irreducibility : there is no shortcut to predict the final state; one must simulate the system step by step. This irreducibility underlies unpredictability and is a core manifestation of complexity.

Three Dimensions for Understanding Software Complexity

The author synthesizes the above perspectives into three complementary dimensions:

Structural dimension (static) — Focuses on discovering the structures in code that implement functional and non-functional requirements (concurrency, communication, memory, storage, redundancy, etc.). Key references: Ousterhout's definition and Simon's hierarchy metric.

Behavioral dimension (dynamic) — Examines actual runtime interactions and interference among components. The primary tool today is observability technology . Key concepts: positive feedback loops, multivariable nonlinear systems (Gurley, Taleb).

Evolutionary dimension (historical) — Investigates why the software evolved into its current form. Understanding evolution starts from design decisions. Metrics: computational irreducibility (Wolfram) and thermodynamic depth (Mitchell); also Gall's principle that working complex systems evolve from working simple systems.

The article concludes with links to the author's related Zhihu articles for deeper exploration of each dimension.