principles:keep_it_simple_stupid
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
principles:keep_it_simple_stupid [2013-02-02 13:16] – external edit 127.0.0.1 | principles:keep_it_simple_stupid [2021-10-20 20:59] – old revision restored (2019-12-03 16:25) christian | ||
---|---|---|---|
Line 12: | Line 12: | ||
* [[contexts: | * [[contexts: | ||
- | + | * [[contexts: | |
+ | * [[contexts: | ||
+ | * [[contexts: | ||
===== Principle Statement ===== | ===== Principle Statement ===== | ||
- | A simple solution is better than a complex one---even if the solution looks stupid. | + | 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 " | + | 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 " |
A solution that follows the KISS principle might look boring or even " | A solution that follows the KISS principle might look boring or even " | ||
- | 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 |
- | + | ||
===== Rationale ===== | ===== Rationale ===== | ||
Line 33: | Line 32: | ||
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." | ||
+ | |||
+ | 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": | ||
Line 46: | Line 52: | ||
* Avoid general solutions needing parameterization. A specific solution will suffice. | * Avoid general solutions needing parameterization. A specific solution will suffice. | ||
* ... | * ... | ||
+ | |||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | See section [[#contrary principles]]. | ||
Line 52: | Line 63: | ||
The principle was coined by the American engineer Kelly Johnson referring to the requirement that a military aircraft should be repairable with a limited set of tools under combat conditions ((Ben R. Rich: // | The principle was coined by the American engineer Kelly Johnson referring to the requirement that a military aircraft should be repairable with a limited set of tools under combat conditions ((Ben R. Rich: // | ||
- | The principle of striving for simple solutions sometimes is also called "(rule of) simplicity" | + | The principle of striving for simple solutions sometimes is also called "(rule of) simplicity" |
Line 58: | Line 69: | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
/* * [[wiki: | /* * [[wiki: | ||
- | /* * [[wiki:Examined]]*/ | + | /* * [[wiki:Questioned]]*/ |
- | * [[wiki: | ||
- | /* * [[wiki:Questioned]]*/ | + | [[wiki: |
+ | |||
+ | [[wiki:Examined]]: While the preference for simple solutions can be considered trivially intuitive, there has been some work relating simplicity or rather complexity and certain quality attributes. But as there is no universally applicable complexity metric and not even a commonly agreed upon clear definition of simplicity, research is bound to examine certain aspects of KISS independently. | ||
+ | |||
+ | The following hypotheses can be stated: | ||
+ | - Simpler solutions are faster to implement. | ||
+ | - Simpler solutions yield fewer 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 yield more reliable software, i.e. fewer defects show up after releasing the software. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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: // | ||
+ | |||
+ | Furthermore software cost estimation techniques are partly based on complexity judgments((Barry W. Boehm: //Software Engineering Economics//, | ||
+ | |||
+ | 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/ | ||
Line 71: | Line 99: | ||
==== 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, | + | * [[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, |
* [[You Ain't Gonna Need It]] (YAGNI) | * [[You Ain't Gonna Need It]] (YAGNI) | ||
* [[Rule of Parsimony]] | * [[Rule of Parsimony]] | ||
Line 83: | Line 111: | ||
* **[[Murphy' | * **[[Murphy' | ||
* [[Model Principle]] (MP): There are often simpler ways to build a software system than to model and mirror the real world behavior, which frequently means having more objects and more complicated structures. Nevertheless it is advisable to do so anyway. | * [[Model Principle]] (MP): There are often simpler ways to build a software system than to model and mirror the real world behavior, which frequently means having more objects and more complicated structures. Nevertheless it is advisable to do so anyway. | ||
- | * [[High Cohesion]] (HC): Reducing complexity by not introducing further modules typically leads to a lower cohesion. | ||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
Line 93: | Line 120: | ||
- | ===== Example | + | ===== Examples |
- | FIXME | + | ==== Example 1: Fuzzy Simplicity ==== |
+ | Simplicity is a blurry, partly subjective measure. Sometimes it is difficult to tell what is simpler. The following example shows that: | ||
+ | |||
+ | <code java> | ||
+ | public String weekday1(int dayOfWeek) | ||
+ | { | ||
+ | switch (dayOfWeek) | ||
+ | { | ||
+ | case 1: return " | ||
+ | case 2: return " | ||
+ | case 3: return " | ||
+ | case 4: return " | ||
+ | case 5: return " | ||
+ | case 6: return " | ||
+ | case 7: return " | ||
+ | default: throw new IllegalArgumentException(" | ||
+ | } | ||
+ | } | ||
+ | |||
+ | public String weekday2(int dayOfWeek) | ||
+ | { | ||
+ | if ((dayOfWeek < 1) || (dayOfWeek > 7)) | ||
+ | throw new IllegalArgumentException(" | ||
+ | |||
+ | final String[] weekdays = { | ||
+ | " | ||
+ | |||
+ | return weekdays[dayOfWeek-1]; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Both methods do exactly the same thing. They return a string representing the weekday. Just the implementation is different. Both versions may be seen as simpler than the other depending on the view taken. '' | ||
+ | |||
+ | On the other hand '' | ||
+ | |||
+ | So it's not objectively clear which of the two implementations KISS prefers without saying which complexity metric to apply. But this ambiguity is not a problem since principles are not meant to be unambiguous and objective. Eventually a human developer has to decide which solution to implement and the principles only give guidelines. | ||
===== Description Status ===== | ===== Description Status ===== | ||
/* Choose one of the following and comment out the rest: */ | /* Choose one of the following and comment out the rest: */ | ||
Line 110: | Line 172: | ||
* [[http:// | * [[http:// | ||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/keep_it_simple_stupid.txt · Last modified: 2021-10-20 21:09 by christian