Complexity
When we say something's "complex", does it say more about us or more about the world?
When are things complex? Is complexity a property of the world, or a reflection of our limited cognition?
Sorry for the rhetorical questions. This issue explores complexity. By looking at how the term is used from several angles, hopefully we’ll be able to simplify it and understand it.
In this issue:
How our brains respond to complexity (includes interactive model)
Defining complexity, complication and chaos
How to fight complexity: strategies to apply to your own thinking
Writing simpler software
How our brains respond to complexity
As we become aware that a system is more complex, it takes increasingly more cognitive load to understand it. Our minds respond by creating abstractions. Here is an attempt to create a simple model of this (complex) process:
You are welcome to run and modify this model in your browser.
Defining Complexity, Complication and Chaos
Definitions are always terrible. Here are guidelines that I use:
A complex system has relationships between its members that are difficult to simplify or model. Perhaps more technically, they are non-linear or don’t easily fit a growth curve.
A complicated system is a system with many moving parts.
A dynamic system is a system that changes over time.
A dynamical system is a system that the relationships between entities change over time. The rules themselves change.
A chaotic system is a system that is difficult to predict far in advance, even with perfect information about the starting conditions.
A wonderful example of chaos was produced by Reddit user ben1996123 and made famous via Twitter:
If you would like to implement a chaotic triple pendulum yourself, you should follow Jake VanderPlas’s implementation.
How to fight complexity
Approximate reality
We are happy to sacrifice accuracy to make concepts easier to learn and remember. Earth is a round sphere. New Zealanders are a “team of 5 million”. There is “goodness” in health foods.
Make me the center
Devoid of other context, we will insert ourselves as the reference point. Gravity pulls downwards, relative to me. Big objects, such as cars and trees, are bigger than me.
Make discrete
The world is continuous. Yet we tend to place things into discrete categories. Even though people can distinguish between millions of colours, we only use a few words to describe them. Tree leaves are green. Bark is brown. And of course, gender is binary.
Place things into categories
We would rather have a simpler solar system that’s factually flawed, rather than an accurate one that is complex. Pluto feels like it should be a planet.
Assemble a hierarchy
We constantly create hierarchies, even when the facts don’t align. We prefer categories with rigid barriers, such as birds and mammals, rather than worry about edge cases like the platypus.
Fabricate order
Small, medium, large. Overlaying reality with some sort of pattern will make systems easier to understand.
Apply logistic thinking
Is 10km a long way away? That will depend on what we’re comparing it to. 10km is a (very) long way to walk to the bus stop. It’s not too far when we’re traveling between continents. More generally, our brains intuitively use logarithms when magnitudes increase.
Do you agree with these points? Can you help me to find references to support or refute these suggestions? If we were on Wikipedia, [citation needed] would be added all over the place. Please comment on the post to enrich it with further reading.
Writing simpler software
John Ousterhout recommends that software teams invest up to 20% of their effort on reducing complexity.
Which of these two function signatures is simpler? Assume that n is a numeric type that represents real numbers, e.g. a float in most programming languages. Point is a type that contains two n values.
fn distance_between(x1: n, y1: n, x2: n, y2: n)fn distance_between(a: Point, b: Point)The first approach is used by the Processing programming language for creative coding. There, the designers prefer to use a simpler type system to make things more accessible to new programmers.
To guide us, we could consider “brain oriented programming” as espoused by Philip Winston. I would have used the term brain-compatible programming. When designing data types and software interfaces, we need to stick to a budget of 7 ± 2 parameters.
Support this newsletter by sharing it. To make a financial contribution, please buy me a coffee. Artworks are available as high-resolution images and physical prints by request.