principles:more_is_more_complex
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:more_is_more_complex [2020-10-12 16:26] – old revision restored (2016-01-11 08:47) 159.69.186.191 | principles:more_is_more_complex [2021-09-02 17:57] – old revision restored (2021-09-02 10:44) 65.21.179.175 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | aaaa | + | ====== More Is More Complex (MIMC) ====== |
+ | |||
+ | ===== Variants and Alternative Names ===== | ||
+ | |||
+ | * Less is more | ||
+ | |||
+ | ===== Context ===== | ||
+ | /* fill in contexts here: */ | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | |||
+ | ===== Principle Statement ===== | ||
+ | |||
+ | More is more complex. | ||
+ | |||
+ | |||
+ | ===== Description ===== | ||
+ | |||
+ | Having more lines of code, methods, classes, packages, executables, | ||
+ | |||
+ | 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. | ||
+ | |||
+ | For documentation it simply states that fewer documentation is better. | ||
+ | |||
+ | |||
+ | ===== Rationale ===== | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Regarding documentation it is evident that smaller amounts of documentation are read faster. | ||
+ | |||
+ | |||
+ | ===== Strategies ===== | ||
+ | |||
+ | * 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 into several smaller ones | ||
+ | * Introduce new modules to group related functionality. A [[patterns: | ||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | * Note that [[Miller' | ||
+ | * 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]]. | ||
+ | * Having no documentation is best with respect to MIMC. But of course there are contrary principles. | ||
+ | |||
+ | See also section [[#contrary principles]]. | ||
+ | |||
+ | |||
+ | ===== Origin ===== | ||
+ | |||
+ | The phrase "more is more complex" | ||
+ | |||
+ | The phrase "Less is more" was made famous by the designer and architect Ludwig Mies van der Rohe, the dictum, Less is More came to define the brave, utopian ideals of modernist design and architecture. In fact the phrase originated in Robert Browning' | ||
+ | |||
+ | |||
+ | ===== Evidence ===== | ||
+ | /* Comment out what is not applicable and explain the rest: */ | ||
+ | /* * [[wiki: | ||
+ | /* * [[wiki: | ||
+ | |||
+ | [[wiki: | ||
+ | |||
+ | This phenomenon that the defect density is high for small modules but also rises for large modules is called the " | ||
+ | |||
+ | 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 artifact((Jarrett Rosenberg: //Some Misconceptions About Lines of Code// | ||
+ | |||
+ | 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 [[Model Principle|MP]], | ||
+ | |||
+ | 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 this((John Daly, Andrew Brooks, James Miller, Marc Roper and Murray Wood: //An Empirical Study Evaluating Depth of Inheritance on the Maintainability of Object-Oriented Software// | ||
+ | |||
+ | [[wiki: | ||
+ | |||
+ | ===== Relations to Other Principles ===== | ||
+ | |||
+ | ==== Generalizations ==== | ||
+ | |||
+ | * [[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. | ||
+ | |||
+ | ==== Specializations ==== | ||
+ | |||
+ | ==== Contrary Principles ==== | ||
+ | |||
+ | 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' | ||
+ | |||
+ | * **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. | ||
+ | * [[More Stakeholders, | ||
+ | * [[Navigation Avoidance Principle]] (NAP): When trying to minimize documentation try not to create the need for navigation. | ||
+ | |||
+ | ==== Complementary Principles ==== | ||
+ | |||
+ | * [[Miller' | ||
+ | * [[Document the Hard Stuff]] (DHS): When trying to minimize documentation DHS tells you what you should document and what you can leave out. | ||
+ | * [[Don' | ||
+ | |||
+ | ==== Principle Collections ==== | ||
+ | |||
+ | {{page> | ||
+ | |||
+ | |||
+ | ===== Examples ===== | ||
+ | |||
+ | FIXME | ||
+ | |||
+ | |||
+ | ===== Description Status ===== | ||
+ | /* Choose one of the following and comment out the rest: */ | ||
+ | / | ||
+ | [[wiki: | ||
+ | / | ||
+ | |||
+ | ===== Further Reading ===== | ||
+ | |||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/more_is_more_complex.txt · Last modified: 2021-10-20 21:26 by christian