This is an old revision of the document!
Table of Contents
More Is More Complex (MIMC)
Variants and Alternative Names
More is more complex.
Having more lines of code, methods, classes, packages, executables, libraries etc. always means also to have more complexity (which is bad). This means that given the complexity of the problem is fixed, a suitable compromise for the number of methods, classes, etc. has to be found. Reducing the number of statements per method typically results in the introduction of further methods. Reducing the number of methods per class can be achieved by dividing the class into several smaller classes, etc.
Note that it is actually not the number of lines, methods, classes, etc. that is relevant but the effective number of items that have to be kept in mind for the purpose of understanding. So reducing the number of lines by placing several statements in one line does not help. Neither the introduction of an additional obvious private method exceeding the limit will do any harm. MIMC is just a rule of thumb stating that the introduction of further modules (and the like) usually has a higher complexity as a drawback.
The capabilities of the human mind are certainly limited. If it is necessary to keep a large amount of modules or lines of code in mind, it is difficult to understand. Furthermore if a module is large, it takes a long time to read (and thus to comprehend). And if there are many modules, looking for a particular module takes a long time. And the longer the searching process takes, the more one will have forgotten what has been read previously. This results in worse readability, understandability and this maintainability.
- Avoid many modules
- Merge several modules into one
- Don't introduce a new module but put the functionality into another module
- Avoid big modules
- Divide large modules in several smaller ones
- Note that Miller's Law is often cited in this context but it is doubtful if and to what extend it applies.
- Note that this principle is contrary to itself. Given a desired functionality a certain level of complexity in inevitable. This leads in the extremes either to a large amount of small classes or a large amount of code in a fewer class. The same applies on other levels like number and size of methods, etc. So there is always a tradeoff between MIMC and itself applied to different aspects of the software system.
- Furthermore note that having more classes can be regarded better than having too large classes. See Add More Classes.
See also section contrary principles.
The phrase “more is more complex” is new but can be regarded trivially intuitive to every developer.
Relations to Other Principles
- Keep It Simple Stupid (KISS): MIMC states that having more modules, etc. leads to more complexity. KISS on the other hand is about the avoidance of every form of complexity.
Note that many principles are contrary to MIMC as they favor the introduction of additional modules. This means that it is worthwhile to consider MIMC when considering one of those. Nevertheless this does not mean that this is true the other way around. When considering MIMC, one wouldn't want to consider all principles that have complexity as a disadvantage. So here are those needing consideration:
- More Is More Complex (MIMC): Changing a design to adhere to the MIMC principle may always lead to more complexity concerning another aspect of the system. For example reducing the amount of code in a large method is typically achieved by the introduction of further methods. So there is always a tradeoff between this principle and itself.
- High Cohesion (HC): Not introducing further modules typically leads to a lower cohesion.
- Add More Classes: While MIMC is a very general principle that applies to virtually everything, it may be regarded better to have more classes than bigger classes.
- Miller's Law: This is the law about a conceptual limit often cited as a (user interface) design rule.