User Tools

Site Tools


principles:more_is_more_complex

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
principles:more_is_more_complex [2021-09-02 10:44] – old revision restored (2021-05-19 09:40) 65.21.179.175principles:more_is_more_complex [2021-10-20 21:22] – old revision restored (2017-02-16 11:41) christian
Line 3: Line 3:
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
  
-  * Miller's Law (this is the law about the conceptual limit independent of software development)+  * Less is more
  
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]]  +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:Architecture]] 
 +  * [[contexts:User Interface Design]] 
 +  * [[contexts:Implementation]] 
 +  * [[contexts:Documentation]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 17: Line 21:
 ===== Description ===== ===== Description =====
  
-Having more lines of code, methods, classes, packages, executables, libraries etc. always means also to have more complexity (which is bad). An ideal number can be around sevenwhich means: +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 methodsclasses, 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 classesetc.
-  * seven lines of code per method +
-  * seven methods per class +
-  * seven classes in a sub-system +
-  * etc.+
  
-Of course this is not possible in a realistically-sized software systemSo more realistic values can be debatedSeven parameters to a method is quite much and can be regarded way too manyOn the other hand seven methods per class and seven classes per subsystems are usually too fewAlso seven lines of code per method is sometimes not realistically achievable.+There is both: too large modules (i.eundermodularization) and too small modules (i.eovermodularization). 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).
  
-This means that given the complexity of the problem is fixed, a suitable compromise for the number of methods, classes, etc. has to be foundReducing the number of statements per method typically results in the introduction of further methodsReducing 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 understandingSo 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 harmMIMC is just a rule of thumb stating that the introduction of further modules (and the like) usually has a higher complexity as a drawback.
  
-Furthermore 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. 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 ===== ===== Rationale =====
  
-The human brain can only handle relatively small amount of "items" or "chunks" of information efficiently in the short-time memoryThis cognitive limit is commonly referred to as being "seven plus or minus two" items ((George AMiller: //[[http://www.psych.utoronto.ca/users/peterson/psy430s2001/Miller%20GA%20Magical%20Seven%20Psych%20Review%201955.pdf|The Magical Number SevenPlus or Minus Two: Some Limits on Our Capacity for Processing Information]]//))+The capabilities of the human mind are certainly limited. If it is necessary to keep large amount of modules or lines of code in mind, it is difficult to understandFurthermore 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 timeAnd the longer the searching process takes, the more one will have forgotten what has been read previouslyThis results in worse readabilityunderstandability and thus maintainability.
  
-While the human short-term memory is far more complex than can be expressed in a catchphrase like "7±2", it is certainly true that it is somehow limited. For the validity of the MIMC principle the actual number of items is as irrelevant as the precise inner-workings of the human mind. Short-term memory is undoubtedly limited and exceeding this limit will impose a much higher effort for understanding. This has a negative effect on maintainability and defect introduction.+Regarding documentation it is evident that smaller amounts of documentation are read faster
  
  
 ===== Strategies ===== ===== Strategies =====
  
-  * Divide large module into several smaller ones. +  * Avoid many modules 
-  * Don't introduce a new module if it will be only very small one.+    * Merge several modules into one 
 +    * Don't introduce 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:Parameter Object]] is a typical example for this. 
 + 
 +===== Caveats ===== 
 + 
 +  * 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 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 ===== ===== Origin =====
  
-  * For the short-term memory capacity limit being around "seven plus or minus two" also known as "Miller's Law" the original source is: George A. Miller: //[[http://www.psych.utoronto.ca/users/peterson/psy430s2001/Miller%20GA%20Magical%20Seven%20Psych%20Review%201955.pdf|The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information]]// +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]].
-  * The phrase "more is more complex" is new but can be regarded trivially intuitive to every developer.+
  
  
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* Comment out what is not applicable and explain the rest: */
-  * [[wiki:Proposed]]: FIXME +/*  * [[wiki:Proposed]]*/
- +
-/*  * [[wiki:Examined]]*/+
 /*  * [[wiki:Accepted]]*/ /*  * [[wiki:Accepted]]*/
-/*  * [[wiki:Questioned]]*/ 
  
 +[[wiki: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 ((Victor R. Basili and Barry T. Perricone: //Software Errors and Complexity: An Empirical Investigation//)). 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 this((Chris E. Kemerer: //Software complexity and software maintenance: A survey of empirical research//)).
 +
 +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 size((see Khaled El Emam, Saõda Benlarbi, Nishith Goel, Walcelio Melo, Hakim Lounis, and Shesh N. Rai: //The Optimal Class Size for Object-Oriented Software//)). 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 artifact((Jarrett Rosenberg: //Some Misconceptions About Lines of Code//))((Khaled El Emam, Saõda Benlarbi, Nishith Goel, Walcelio Melo, Hakim Lounis, and Shesh N. Rai: //The Optimal Class Size for Object-Oriented Software//)) and that there are also other methodological problems with these studies((Norman E. Fenton and Martin Neil: //A Critique of Software Defect Prediction Models//)). There is also data which is not explainable by defect models based on the Goldilocks Conjecture((Norman E. Fenton and Martin Neil: //A Critique of Software Defect Prediction Models//)). 
 +
 +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]], [[Low Coupling|LC]], and [[High Cohesion|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 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//))((Barbara Unger and Lutz Prechelt: //The Impact of Inheritance Depth on Maintenance Tasks//)). 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.
 +
 +[[wiki:Questioned]]: The Goldilocks Conjecture, which can be seen as an aspect of MIMC, is disputed. See above.
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
Line 62: Line 84:
 ==== Generalizations ==== ==== Generalizations ====
  
-  * [[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.+  * [[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 ==== ==== Specializations ====
Line 71: Line 93:
  
   * **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.   * **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.
-  * **[[principles:High Cohesion]] (HC)**: Not introducing further modules typically leads to a lower cohesion.+  * **[[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, More Details]] (MSMD): The more stakeholders there are, the more documentation is needed. 
 +  * [[Navigation Avoidance Principle]] (NAP): When trying to minimize documentation try not to create the need for navigation.
  
 ==== Complementary Principles ==== ==== Complementary Principles ====
 +
 +  * [[Miller's Law]]: This is the law about a conceptual limit often cited as a (user interface) design rule.
 +  * [[Document the Hard Stuff]] (DHS): When trying to minimize documentation DHS tells you what you should document and what you can leave out.
 +  * [[Don't Repeat Yourself]] (DRY): Eliminating duplication is a way to reduce complexity.
  
 ==== Principle Collections ==== ==== Principle Collections ====
Line 79: Line 108:
 {{page>collections:OOD Principle Language#Box}} {{page>collections:OOD Principle Language#Box}}
  
-===== Example =====+ 
 +===== Examples =====
  
 FIXME FIXME
 +
  
 ===== Description Status ===== ===== Description Status =====
Line 91: Line 122:
 ===== Further Reading ===== ===== Further Reading =====
  
 +===== Discussion =====
  
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:More Is More Complex|talk page]].
principles/more_is_more_complex.txt · Last modified: 2021-10-20 21:26 by christian