Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Keep It Simple Stupid (KISS)
principles:keep_it_simple_stupid

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
principles:keep_it_simple_stupid [2020-10-12 20:33] – old revision restored (2020-10-12 12:10) 159.69.186.191principles:keep_it_simple_stupid [2020-10-12 20:33] – old revision restored (2013-03-22 15:32) 159.69.186.191
Line 12: Line 12:
  
   * [[contexts:Object-Oriented Design]]   * [[contexts:Object-Oriented Design]]
-  * [[contexts:Architecture]] 
-  * [[contexts:User Interface Design]] 
-  * [[contexts:Implementation]] 
-===== Principle Statement =====l 
  
-A simple solution is better than a complex one, even if the solution looks stupid. + 
 +===== Principle Statement ===== 
 + 
 +A simple solution is better than a complex one---even if the solution looks stupid.
  
  
 ===== Description ===== ===== Description =====
  
-The KISS principle is about striving for simplicity. Modern programming languages, frameworks and APIs have powerful means to create sophisticated solutions for various kinds of problems. Sometimes developers might feel tempted to write "clever" solutions that use all these complex features. The KISS principle states that a solution is better when it uses less inheritance, less polymorphism, fewer classes, etc.+The KISS principle is about striving for simplicity. Modern programming languages, frameworks and APIs have powerful means to create sophisticated solutions for various kinds of problems. Sometimes developers might feel tempted to write "clever" solutions that use all these complex features. The KISS principle states that a solution is better when is uses less inheritance, less polymorphism, fewer classes, etc.
  
 A solution that follows the KISS principle might look boring or even "stupid" but simple and understandable. The KISS principle states that there is no value in a solution being "clever" but in one being easily understandable. A solution that follows the KISS principle might look boring or even "stupid" but simple and understandable. The KISS principle states that there is no value in a solution being "clever" but in one being easily understandable.
  
-This does not mean that features like inheritance and polymorphism should not be used at all. Rather they should only be used when they are necessary or there is some substantial advantage+This does not mean that features like inheritance and polymorphism should not be used at all. Rather they should only be used when they are necessary or there is some substantial advantage in using them. 
 + 
 ===== Rationale ===== ===== Rationale =====
  
Line 32: Line 33:
  
 The advantage of simplicity is even bigger when the person who maintains the software is not the one who once wrote it. The maintainer might also be less familiar with sophisticated programming language features. So simple and stupid programs are easier to maintain because the maintainer needs less time to understand them and is less likely to introduce further defects. The advantage of simplicity is even bigger when the person who maintains the software is not the one who once wrote it. The maintainer might also be less familiar with sophisticated programming language features. So simple and stupid programs are easier to maintain because the maintainer needs less time to understand them and is less likely to introduce further defects.
- 
-One reason to create more complex code is to make it more flexible to accommodate further requirements. But one cannot know in what way to make it flexible or if that flexibility will be ever needed. 
- 
-"When you make your code more flexible or sophisticated than it needs to be, you over-engineer it. Some do this because they believe they know their system’s future requirements. They reason that it’s best to make a design more flexible or sophisticated today, so it can accommodate the needs of tomorrow. That sounds reasonable, if you happen to be a psychic." - Refactoring To Patterns - Joshua Kerievsky. 
- 
-Another reason to create more complex code is to make optimizations. An optimized code is a more complex code. Pareto principle applies also in code: a program spend most of the time in a small portion of the code, so it will be wise to concentrate the effort to optimize only that part of the code. Another best practice is to follow the  
-"Three rules of optimization": (1. Don't, 2. Don't... Yet, 3. Profile before optimizing), which make sense: to optimize only the code with performance problems. (First author: Michael A. Jackson) 
  
  
Line 78: Line 72:
 The following hypotheses can be stated: The following hypotheses can be stated:
   - Simpler solutions are faster to implement.   - Simpler solutions are faster to implement.
-  - Simpler solutions yield fewer implementation faults (which reduces testing effort). +  - Simpler solutions yield less implementation faults (which reduces testing effort). 
-  - Simpler solutions are easier to maintain, i.e. detecting and correcting defects is more effective and efficient. +  - Simpler solutions are easier to maintain, i.e. detecting and correcting defects is effective and efficient. 
-  - Simpler solutions yield more reliable software, i.e. fewer defects show up after releasing the software.+  - Simpler solutions yield more reliable software, i.e. less defects show up after releasing the software.
  
 All these hypotheses can be examined with respect to different complexity metrics. All these hypotheses can be examined with respect to different complexity metrics.
  
-Hypothesis 1 is true by definition. If the solution cannot be implemented quickly, it is not simple. +Hypothesis 1 can be regarded true by definition. If the solution cannot be implemented fast, it is not simple. 
  
-Though hypotheses 2 and 3 are not true by definition but they can be regarded intuitively clear. Nevertheless there is some research. In ((Virginia R. Gibson and James A. Senn: //[[http://dl.acm.org/citation.cfm?id=62073|System Structure and Software Maintenance Performance]]//)) a system was improved in two steps resulting in three variants of the same system. Several metrics show that the improvements reduced complexity. 36 programmers with varying experience conducted three different maintenance tasks and their performance was measured. The results indicate that the improvements also improved maintainability. Several other studies support the correlation between complexity and maintainability((Chris F. Kemerer: //[[http://link.springer.com/article/10.1007%2FBF02249043?LI=true|Software complexity and software maintenance: A survey of empirical research]]//)).+Though hypotheses 2 and 3 are not true by definition but they can be regarded intuitively clear. There is only few scientific research concerning these questions directly. As a specific aspect of complexity, 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. Typically there are good ways and bad ways of using inheritance. And rarely 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.
  
-Furthermore software cost estimation techniques are partly based on complexity judgments((Barry W. Boehm: //Software Engineering Economics//, IEEE)). So complexity---although this normally relates the complexity of the problem and not to the complexity of the solution---is a known cost factor which may be accounted to maintenance.+Furthermore software cost estimation techniques are partly based on complexity judgments((Barry W. Boehm: //Software Engineering Economics//, IEEE)). So complexity---although this normally relates the complexity of the problem and not to the complexity of the solution---is a known cost factor.
  
-Lastly hypothesis 4 is likely to be false. Several studies relating complexity metrics and post-release reliability show that module size in lines of code predicts reliability at least as good as the McCabe metric (also called cyclomatic complexity) ((see Albert Endres, Dieter Rombach: //A Handbook of Software and Systems Engineering//, p. 168ff.)). Assuming cyclomatic complexity correctly depicts the complexity of a module, reliability should not the reason for applying KISS.+Lastly hypothesis 4 is likely to be false. Several studies relating complexity metrics and post-release reliability show that module size in lines of code predicts reliability at least as good as the McCabe metric (also called cyclomatic complexity) ((see Albert Endres, Dieter Rombach: //A Handbook of Software and Systems Engineering//, p. 168pp.)). Assuming cyclomatic complexity correctly depicts the complexity of a module, reliability should not the reason for applying KISS.
  
  
Line 99: Line 93:
 ==== Specializations ==== ==== Specializations ====
  
-  * [[More Is More Complex]] (MIMC): KISS states that one should strive for simplicity. MIMC makes this more concrete stating that more of anything (methods, classes, lines of code, ...) increases complexity.+  * [[More Is More Complex]] (MIMC): KISS states that one should strive for simplicity. MIMC makes this more concrete stating that more of anything (methods, classes, lones of code, ...) increases complexity.
   * [[You Ain't Gonna Need It]] (YAGNI)   * [[You Ain't Gonna Need It]] (YAGNI)
   * [[Rule of Parsimony]]   * [[Rule of Parsimony]]
Line 172: Line 166:
   * [[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877917|The Art of Unix Programming: Rule of Simplicity]]   * [[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877917|The Art of Unix Programming: Rule of Simplicity]]
  
-===== Discussion ===== 
- 
-Discuss this wiki article and the principle on the corresponding [[talk:principles:Keep It Simple Stupid|talk page]]. 
principles/keep_it_simple_stupid.txt · Last modified: 2021-10-20 21:09 by christian