Rule 1: effort to add/change something in an existing system = size of the change * complexity of the system
Rule 2: complexity of the system = effort it requires to understand it
Rule 3: system complexity grows as the inverse exponential function of how much its builders understand the system * rate of effort
Clarifications:
- Effort = skill * time
- For small teams you generally can add effort towards the same addition/change, for large ones you generally cannot.
- Rule 1 might be tempered (or aggravated) by how acquainted or unacquainted a team is with their own system.
- Things to be done are either: additions or changes. In any case, it’s about improving the system without breaking what is already working in the system.
- Rule 3 is necessarily more complex mathematically because it is what breaks linearity and brings in exponentiality.
Explanation:
- Why complexity is key? Because it determines the overall long-term/asymptotic effort of doing anything in a system.
- Understanding determines how quickly someone can fix problems since they are easy to find; and how quickly they can add features since it’s clear how the new features can coexist with the existing ones without breaking them.
- Complexity tends to increase exponentially and can quickly dwarf enormous efforts, even of large teams composed of skilled people that spent a long time understanding the system.
- No training can dwarf large complexity either, because a sufficiently complex system cannot be understood. It can only be understood if it’s simplified.
- Understanding gives you a reliable representation of what you understand. You don’t just hold the elements of the system, but also all of their interrelations. I suspect there’s a n^2 phenomenon here at play, where the effort of understanding is quadratic with the number of elements; this is also perhaps related to LLM attention training, which is also n^2 since it holds the relationship of any element against each of the other ones.
- Minimizing complexity is the only way to retain speed in the long term.
- Speed of development is a great metric, but not just the speed on the first week or month of the project. The speed that matters is that over the entire lifecycle of the system.
- Interesting corollary: complexity = lines of code ^ 2