iTranslated by AI
Rethinking Simplicity
An article I wrote a while ago. An update on my current thoughts about "simple".
Simplicity is selecting a function f where cognitive load is relatively low compared to the total amount of value provided by the system.
Cognitive Load = f(Total amount of value provided by the system)
Cognitive load is the ease of understanding within the finite memory of a human; it is human-friendliness.
There are various ways to look at the total value a system provides, but my current understanding is that it's the "product of user scale and functional value (number of features)." Please think of "total amount" not as a cumulative value, but as functional value (number) multiplied by MAU (Monthly Active Users) or DAU (Daily Active Users). In other words, it is a somewhat instantaneous value.
Generally, as the total value provided by the system increases, the system becomes more complex, and the cognitive load for humans maintaining or developing features increases. For example, if the number of users increases, infrastructure must be strengthened, and since more people are affected, security requirements become higher, and compliance aspects must be strictly followed. Depending on the service level of the system (e.g., handling money or lives), uptime and recovery time become crucial. Also, separate from the number of users, increasing the number of features leads to more infrastructure and programming code to provide those features.
There is a correlation between the total value provided by the system and the cognitive load on the humans who maintain and develop it. The diagram below is an illustration of this concept.
However, in reality, it rarely becomes such a clean linear progression from the origin. This is because in professional-level development, code is rarely written from scratch (from zero); from the infrastructure level to the app and code levels, various OSS and paid libraries are provided as development aids. While cognitive load increases by the learning cost of these libraries in the early stages of development, the provided value increases accordingly. It seems more like a linear function with a constant term added to the y-axis. The diagram below shows this concept.
In modern development, since we basically use some kind of framework, the explosion of cognitive load can be suppressed to some extent. However, if we were to develop without these frameworks, without using development models (like the MVC pattern) or architectures that suppress cognitive load, and if the code lacked patterns, rules, or consistency, the cognitive load would increase exponentially as shown in the diagram below. Furthermore, each framework has its own design philosophy, and if you try to provide value that exceeds that philosophy, the cognitive load will also increase. For example, the front-end framework Vue (assuming the use of Options API) has a very low hurdle for beginners, with low initial learning costs and cognitive load, but as development progresses, it becomes less adept at complex processing that combines functions. React, another front-end framework, has a higher learning cost, but allows development to proceed while relatively suppressing cognitive load even in the later stages of development. Of course, there are limits somewhere, and it also depends heavily on how the developer writes the code.
We've seen that by successfully incorporating frameworks and architectures, cognitive load can be suppressed. Ideally, I think a logarithmic function like the one in the diagram below would be ideal.
So far, I have explained the relationship between the total amount of value provided and cognitive load.
Adopt the appropriate framework or architecture for the total amount of value your system aims to provide
In the diagram below, I have overlaid all the functions for cognitive load that appeared in the previous section.
What I want to say in this article is to "Adopt the appropriate framework or architecture for the total amount of value your system aims to provide." For example, in the diagram below, if the total amount of value you want to provide falls into Zone A, you would choose method ①, which involves building from scratch or using a lightweight framework/architecture. Similarly, choose ① for Zone B, ③ for Zone C, and ④ for Zone D.
Of course, it is inherently difficult to estimate the total amount of value you want to provide in the first place, and the ability to know which framework or architecture is suitable for that estimated amount is another matter entirely.
Therefore, some might take an approach where they proceed with development assuming Zone B, and if the service becomes a hit and starts entering Zone C, they endure it while working hard to replace it with ③ or ④ before it enters Zone D.
There seem to be various other routes as well, so please do think about them.
Check out this article as well (approx. 2 min read)
Discussion