principles:keep_it_simple_stupid
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| principles:keep_it_simple_stupid [2025-11-04 22:41] – created colequinn8555 | principles:keep_it_simple_stupid [2025-11-25 10:53] (current) – old revision restored (2021-10-20 21:09) christian | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | If you happen to be watching the Democratic primaries you probably know every single of the candidates have introduced their universal healthcare policies. Those who is going to be Christ Jesus need to view this very clearly. [[https:// | + | ====== Keep It Simple Stupid |
| - | Take a software program or home-study the local language. When you're getting there, show interest in learning | + | ===== Variations |
| - | There it is. Not one feeble person was among their tribe. That's over 5 million plus people, absolutely no one suffering. This policy is still in their place and is established on better promises now because of the blood of Jesus. | + | * (Rule of) Simplicity |
| + | * KISS may also mean " | ||
| - | During almost the entire package talk I have yet to listen the term "bureaucracy". The thing that occurs when the government gets a anything is create bureaucracy. I've heard of 12,000 additional IRS agents that end up being needed to enforce | + | **Remarks**: |
| - | This involving healthcare training can also prepare you for a career in an institution or clinic. But if you know that you would rather work in private homes, you can tailor your 新潟市中央区 坐骨神経痛 training to intention. | ||
| - | You: OK, well I am aware that sometimes people obtain a bit nervous when they require their first acupuncture treatment so this is exactly what I'll do for your site. we have a free report process to chose the most beneficial acupuncturist for your own benefit or all your family and before you appear I'll send that for you through the mail so you've an involving what locate in an Acupuncture clinic, does that make sense? | + | ===== Context ===== |
| - | Kay is my accountant los angeles. Last month she called me just additional medications sure I got my quarterly taxes for their way the actual world proper amounts and for the proper influence. I have to confess I was impressed that they was do you want to me. | + | * [[contexts: |
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| - | See, a lot of healthcare services might hesitate to you should try it because of this word ' | + | ===== Principle Statement ===== |
| - | Sometime in mid-October of 2008, I managed to injure my left shoulder in a major accident while doing some work inside your own home. I was moving some boxes that Got stored in the garage and that i stumbled over something. Your past process I managed capture my fall by stretching my left-hand Osteopathic clinic out towards wall. My hand grasped the wall, but the momentum kept my body moving ahead. The result was very painful since i forced my arm and shoulder back in an unnatural position. | + | A simple solution is better than a complex one, even if the solution looks stupid. |
| - | Last time I set on see Henry he laughed and said that acupuncture will return the balance in requires by clearing the meridians. But kind continue to help keep your body on regularly in order to bare this balance. Exercise and diet is the only method to do all of this. | ||
| - | Under our current 新潟市中央区 坐骨神経痛 system, associated with dollars are spent every year for antidepressant medications. But, they are " | + | ===== Description ===== |
| - | That's all there usually it. If you have the remedies | + | The KISS principle is about striving for simplicity. Modern programming languages, frameworks and APIs have powerful means to create sophisticated solutions |
| + | |||
| + | 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. | ||
| + | |||
| + | ===== Rationale ===== | ||
| + | |||
| + | A simpler solution is better than a complex one because simple solutions are easier to maintain. This includes increased readability, | ||
| + | |||
| + | The advantage | ||
| + | |||
| + | 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' | ||
| + | |||
| + | 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 spends 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": | ||
| + | |||
| + | |||
| + | ===== 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: | ||
| + | |||
| + | * Avoid inheritance, polymorphism, | ||
| + | * Avoid low-level optimization | ||
| + | * 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]]) | ||
| + | * For slightly unrelated but rather small pieces of functionality use private methods instead of an additional class. | ||
| + | * Avoid general solutions needing parameterization. A specific solution will suffice. | ||
| + | * ... | ||
| + | |||
| + | |||
| + | ===== Caveats ===== | ||
| + | |||
| + | See section [[#contrary principles]]. | ||
| + | |||
| + | |||
| + | ===== Origin ===== | ||
| + | |||
| + | 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" | ||
| + | |||
| + | |||
| + | ===== Evidence ===== | ||
| + | /* Comment out what is not applicable and explain the rest: */ | ||
| + | /* * [[wiki: | ||
| + | /* * [[wiki: | ||
| + | |||
| + | |||
| + | [[wiki: | ||
| + | |||
| + | [[wiki: | ||
| + | |||
| + | 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, | ||
| + | |||
| + | 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//, | ||
| + | |||
| + | |||
| + | ===== Relations to Other Principles ===== | ||
| + | |||
| + | ==== Generalizations ==== | ||
| + | |||
| + | ==== 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. | ||
| + | * [[You Ain't Gonna Need It]] (YAGNI) | ||
| + | * [[Rule of Parsimony]] | ||
| + | * [[Rule of Robustness]] | ||
| + | |||
| + | ==== Contrary Principles ==== | ||
| + | |||
| + | 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 generally applicable solution typically is not simple anymore. | ||
| + | * **[[Murphy' | ||
| + | * [[Model Principle]] (MP): There are often simpler ways to build a software system | ||
| + | |||
| + | ==== Complementary Principles ==== | ||
| + | |||
| + | ==== Principle Collections ==== | ||
| + | |||
| + | {{page> | ||
| + | {{page> | ||
| + | |||
| + | |||
| + | ===== Examples ===== | ||
| + | |||
| + | ==== 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 ===== | ||
| + | /* Choose one of the following and comment out the rest: */ | ||
| + | / | ||
| + | [[wiki: | ||
| + | / | ||
| + | |||
| + | ===== Further Reading ===== | ||
| + | |||
| + | * [[wiki> | ||
| + | * [[wp> | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | |||
| + | ===== Discussion ===== | ||
| + | |||
| + | Discuss this wiki article and the principle on the corresponding [[talk: | ||
principles/keep_it_simple_stupid.1762292464.txt.gz · Last modified: by colequinn8555
