Skip to Content

2023.06.27

Complexity, the Spirit Demon

An axiom in software development is that "complexity is bad", and we know that introducing complexity into a codebase can cause problems. A simpler solution is a better solution. But can we understand how complexity exists in our systems beyond knowing it when we see it?

Subject:

Software Development, Complexity

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime

Complexity is bad! We do not want complexity in our systems. We want nice, simple systems. But what is complexity?

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

  • John Ousterhout, A Philosophy of Software Design

“Hard to understand” and “hard to modify” are relative and contextual measures that make us ask the question “hard for who?“. Is there a way we can create a more metrical analysis of a systems complexity?

No technique has yet been devised for the measurement of complexity that can be applied to most complex situations such that the complexity of those situations can be compared one to another in a way that provides significant understanding.

  • Vincent Vesterby, Measuring complexity: Things that go wrong and how to get it right

Okay great. What can we do instead?

There may be no real way to measure complexity, and instead focus should be on “system understandability”. This is again, kind of a tricky subjective proposition. At the very least, we can see that quantitative approaches alone are inadequate.

Understanding the system becomes an exercise in creating conceptual integrity.

Conceptual Integrity is, to quote William Griswold, “the principle that anywhere you look in your system, you can tell that the design is part of the same overall design”[ref]. The term comes from Fred Brooks, who forwards it as the solution to the question:

…one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?

  • Fred Brooks, The Mythical Man-Month

Brooks and Vesterby seem to agree on the nature of complex systems – that the complexity is the point of these systems, and any attempt to measure or summarize them is to lose sight of what makes them meaningful in the first place.

The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties by experiment. This paradigm worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence … [complexity is] thus impeding conceptual integrity.

  • Fred Brooks, No Silver Bullet

This aligns with Deleauze and Guatarri, who note that nature of a rhizome-like system composed of a density of heterogenous nodes, each connected to any other inherently strains against the structure of the tree. Casting the rhizome to the tree can be done, but is an exercise of power – the rhizome will always reassert itself. Whats more, Alexander shows us that there are a huge number of possible tree structures per graph. For a rhizome of sufficient size (and therefor complexity), there is essentially an infinite number of possible trees.

Vesterby again notes that the nature of a sophisticated complex system is one of dense interrelations;

Developed systems are composed of subsystems, which are themselves made up of lesser systems. To understand the whole, it is necessary to understand each of these hierarchic levels, what they are and how they interrelate one with another.

  • Vesterby

Sarafen, in an unpublished essay, notes that complexity in a software system can be greatly reduced by documentation and by taking an approach to that documentation informed by educational theory. On the face of it, the addition of more content and documents to an information system – increasing the number of types of things, the number of things, and the number of relationships between things – should make the system more complex. But the opposite is true – by adding more context and information, and by taking the posture that the “for who” is a beginner, the system becomes more understandable and therefor, according to Ousterhout, more simple. As Sarafen says, “the beginner is the doorway of understanding”.

Okay great, but how do we measure complexity?

Complexity in a system cannot be measured directly because complexity is not a natural property of systems. Systems exist in a state of not-separateness, the rhizome, the network. In order to understand systems, humans have to decompose the system into a structure of nested sub-systems that can be understood in order to make predictions about the systems behavior and reliably make adjustments to the system. Complexity is a human construct that is the result of this decomposition, a relative and contextual measure for how an individual can understand a particular decomposition.

Ironically, I think the jokey grug-brain definition is in fact the closest to the reality. Complexity is the spirit demon, it resides in us.

Readings

Elsewhere

software-development
complexity

© 2026