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.
There is both: too large modules (i.e. undermodularization) and too small modules (i.e. overmodularization). Either there is too much complexity in a module (MIMC applied to one module) or there is too much complexity between the modules (MIMC applied to the number of modules).
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.
See also section contrary principles.
The phrase “more is more complex” is new but can be regarded trivially intuitive to every developer. There is also some research concerning certain aspects of MIMC. See section evidence.
Examined: There is some research relating module size to certain quality attributes like maintenance cost, error density, etc. Basili and Perricone studied maintenance data of Fortran programs for aerospace applications 1). They found that the smaller modules had a higher error density than the larger ones. At first this seems to contradict MIMC. But assuming there is a certain essential complexity of the problem, this complexity has to be implemented somehow. Either this leads to a few large modules or many smaller ones. In the latter case the complexity is in the relationships and interactions between the modules instead of the modules themselves. So too small modules result in more modules and more complex communication among them. Other studies seem to confirm this2).
This phenomenon that the defect density is high for small modules but also rises for large modules is called the “Goldilocks Conjecture”. As a result there is an optimal module size which is neither too small, nor too big. Several publications claim to have found this optimal module size3). Depending on the programming language used, these values typically are claimed to be a few hundred lines of code. Note that most of these studies are in the context of procedural programming.
This sounds intuitive but the Goldilocks Conjecture is disputed. Some point out that the negative correlation between defect density and size is just a mathematical artifact4)5) and that there are also other methodological problems with these studies6). There is also data which is not explainable by defect models based on the Goldilocks Conjecture7).
The relationship between module size and defect proneness is complex and not clear. Furthermore modularization is not only a task in terms of module size. The more interesting aspect is how to assign responsibilities to modules. So apart from module size there are many other aspects influencing modularization (see especially MP, LC, and HC) which makes it hard to isolate the pure effect of size.
This is an important research question but as MIMC is just a qualitative rule of thumb (just as the other principles are). So the principle can be deemed helpful despite the Goldilocks Conjecture being disputed.
As a specific aspect of MIMC, complexity through deep inheritance relations is known to reduce effectiveness and efficiency of maintenance. There are controlled experiments showing this8)9). On the other hand these results are limited as there may be many factors which are neglected by the experiment. Most notably in these experiments maintenance tasks where carried out on systems with artificially constructed inheritance hierarchies. It is undisputed hat there are good ways and bad ways of using inheritance. And it is doubtful that there are several equally good solutions for the same problem only differing in the depth of inheritance. So there is some evidence but no “proof” that deep inheritance hampers maintenance.
Questioned: The Goldilocks Conjecture, which can be seen as an aspect of MIMC, is disputed. See above.
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:
Discuss this wiki article and the principle on the corresponding talk page.