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 revision Previous revision
Last revision Both sides next revision
principles:more_is_more_complex [2021-09-02 17:57]
65.21.179.175 old revision restored (2021-05-19 09:40)
principles:more_is_more_complex [2021-10-20 21:22]
christian old revision restored (2017-02-16 11:41)
Line 3: Line 3:
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
  
 +  * Less is more
  
 ===== Context ===== ===== Context =====
Line 11: Line 12:
   * [[contexts:User Interface Design]]   * [[contexts:User Interface Design]]
   * [[contexts:Implementation]]   * [[contexts:Implementation]]
 +  * [[contexts:Documentation]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 24: Line 26:
  
 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. 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 ===== ===== 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, understandability and this maintainability.+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 thus maintainability
 + 
 +Regarding documentation it is evident that smaller amounts of documentation are read faster
  
  
Line 45: Line 51:
   * 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.   * 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]].   * 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]]. See also section [[#contrary principles]].
Line 88: Line 95:
   * **[[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.    * [[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.   * [[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 ====
principles/more_is_more_complex.txt · Last modified: 2021-10-20 21:26 by christian