Symptoms of Complexity
2025-02-16 19:45
Status: #adult
Tags: #philosophy #software #design #books
Symptoms of Complexity
There are three main ways in which complexity may manifest itself:
- Change Amplification: A seemingly simple change requires code modification in many different places.
- This is a problem that is normally solved with abstraction. One should be guided by the principal of "Do not repeat yourself"
- Imagine if you need to change every button in a website when trying to change the color of those buttons..
- Cognitive load: How much does a developer needs to know to complete a task. A higher cognitive load means that developers have to spend more time learning the required information, and there is a greater risk of bugs because they might have missed something important (ehm ehm STSAFE)
- Suppose a function in C allocates memory, returns a pointer to that memory, and assumes that the caller will free the memory. If the developer failed to free the memory then there will be a leak and things will not be happy. RAII could help here for example!
- Often, system designers assume that the complexity can be measured by the lines of code => a shorter implementation doesn't have to be simpler! There is normally some added cognitive load when reducing implementation to fewer lines of code.
- Unknown unknowns: What piece of code to change to complete a task? What information does the developer need to carry the task correctly?
- These are the worst since there is something that we must know but there is no way for us to find out what it is, or even whether there is an issue..
- By the time we find out it will be too late :(
- The only way to be certain is to read every line of code in this system which is practically impossible for large systems. Even reading all lines of code might not help since there might be some assumption or subtle design decision that was never documented.
One of the most important goals of good design is for a system to be obvious. This is the opposite of high cognitive load and unknown unknowns. In an obvious system, a developer can quickly understand how the existing code works and what is required to make a change. An obvious system is one where a developer can make a quick guess about what to do, without thinking very hard, and yet be confident that the guess is correct.