principles:keep_it_simple_stupid
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:keep_it_simple_stupid [2021-02-01 21:12] – old revision restored (2020-12-10 03:53) 95.216.157.202 | principles:keep_it_simple_stupid [2021-09-02 14:01] – old revision restored (2021-09-02 10:22) 65.21.179.175 | ||
---|---|---|---|
Line 6: | Line 6: | ||
* KISS may also mean "Keep it short and simple", | * KISS may also mean "Keep it short and simple", | ||
- | **Remarks**: | + | **Remarks**: |
Line 15: | Line 15: | ||
* [[contexts: | * [[contexts: | ||
* [[contexts: | * [[contexts: | ||
- | ===== Principle Statement =====l | + | * |
+ | ===== 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. | ||
Line 24: | Line 25: | ||
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 ===== | ||
- | A simpler solution is better than a complex one because simple solutions are easier to maintain. This includes increased readability, | + | A simpler solution is better than a complex one because simple solutions are easier to maintain. This includes increased readability, |
- | The advantage of simplicity is even bigger | + | The advantage of simplicity is even more significant |
- | 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. | + | One reason to create more complex code is to make it more flexible to accommodate further requirements. But one cannot know how 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. | + | "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. |
- | Another reason to create more complex code is to make optimizations. An optimized code is a more complex code. Pareto principle | + | Another reason to create more complex code is to make optimizations. An optimized code is a more complex code. The Pareto principle also applies |
"Three rules of optimization": | "Three rules of optimization": | ||
Line 43: | Line 44: | ||
===== Strategies ===== | ===== Strategies ===== | ||
- | This is a very general principle so there is a large variety of possible strategies to adhere more to this principle largely depending on the given design problem: | + | This is a very general principle, so there is a large variety of possible strategies to adhere more to this principle largely depending on the given design problem: |
* Avoid inheritance, | * Avoid inheritance, | ||
- | * Avoid low-level optimization of algorithms especially when involving Assembler, bit-operations, | + | * Avoid low-level optimization of algorithms, especially when involving Assembler, bit-operations, |
* Use simple brute-force solutions instead of complicated algorithms. Slower algorithms will work in the first place. | * Use simple brute-force solutions instead of complicated algorithms. Slower algorithms will work in the first place. | ||
* Avoid numerous classes and methods as well as large code blocks (see [[More Is More Complex]]) | * Avoid numerous classes and methods as well as large code blocks (see [[More Is More Complex]]) | ||
Line 63: | Line 64: | ||
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 86: | Line 87: | ||
Hypothesis 1 is true by definition. If the solution cannot be implemented quickly, it is not simple. | 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: // | + | 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//, | + | 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//, | + | 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 108: | Line 109: | ||
Note that many principles are contrary to KISS. This means that it is worthwhile to consider KISS when considering one of those. Nevertheless this does not mean that this is true the other way around. When considering KISS, one wouldn' | Note that many principles are contrary to KISS. This means that it is worthwhile to consider KISS when considering one of those. Nevertheless this does not mean that this is true the other way around. When considering KISS, one wouldn' | ||
- | * **[[Generalization Principle]] (GP)**: This is the directly converse principle. A solution that is generally applicable typically is not simple anymore. | + | * **[[Generalization Principle]] (GP)**: This is the directly converse principle. A generally applicable |
* **[[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. |
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
Line 154: | Line 155: | ||
</ | </ | ||
- | 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. | + | 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 '' | + | On the other hand "weekdays1" |
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. | 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. |
principles/keep_it_simple_stupid.txt · Last modified: 2021-10-20 21:09 by christian