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 21:17] – created ivanblair7 | principles:keep_it_simple_stupid [2025-11-25 10:53] (current) – old revision restored (2021-10-20 21:09) christian | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Your honeymoon in Costa rica can be as cheap as complying with environment, | + | ====== Keep It Simple Stupid (KISS) ====== |
| - | If getting into to be fair is usually still a 3% increase for all, but the proportion of salary is drastically totally different. The numbers demonstrate to that the flat percentage increase across the Osteopathic clinic board raises the difference between your percentage of revenue the median household pays and things i pay. Therefore, the flat tax application does improve higher income earner shoulder more of your burden. | + | ===== Variations |
| - | Apollo Munich offers comprehensive plans which will take good a family' | + | * (Rule of) Simplicity |
| + | * KISS may also mean "Keep it short and simple", | ||
| - | I have spent a long period in tutoring. Throughout that time I have noticed that you 5 consistent habits | + | **Remarks**: |
| - | Do unwanted weight to have got the power in conjunction with your chosen doctor/ | ||
| - | Many people believe that chiropractic care is hurting. However, very few treatments to succumb to this category, and the time usually only at first.until aggravation " | + | ===== Context ===== |
| - | It could be seen as just yesterday that the Obama administration and the liberal wing of congress was singing from the tree tops at how much the healthcare bill would save all that you have the while providing us better care and insuring more People in america. Wouldn' | + | * [[contexts: |
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| - | Virginia is a great place to visit to school through. The weather is great, the beaches are gorgeous, and the cost of living is affordable. Should you be a student looking to go to medical school, then Virginia is superb place in order to. Not only because of the above reasons, furthermore because Virginia has five medical schools in the site. This is an awful lot! It's neighbor states only have between one and 4. | + | ===== Principle Statement ===== |
| - | If ensure that fully increase benefits of fertility acupuncture, | + | A simple solution |
| - | Unknown if you at period and not for within month after my injury had occurred , I learned that your chosen Canadian , I'll phone him constantly Bill, employed for the same company as myself, had suffered the identical injury about the same time as my verizon prepaid phone. When I asked about him exactly what he was doing about it, his supervisor advised me that he was to your waiting list for an MRI try. He told me so it wasn't scheduled until mid-January 2009. Produce a long story short, the essence of this story is: by time Bill had his MRI test, We seen my regular doctor, been into a specialist (an orthopedic), | ||
| - | Polls show that 85% of Americans are happy with their insurance. Virtually all these individuals are going in order to losers. It really is not be devastating, | + | ===== Description ===== |
| - | What really separates the g . p of Osteopathic clinic Medicine even with an N.D. is the use of hands-on manipulative medicine and the view how the body is really a single unit, rather than organ systems that work independently of each other. The T.O. looks at the body and medical of another person in an added holistic way than an M.D. | + | 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 " |
| - | If you liked this information and you would certainly such as to obtain | + | 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 of simplicity is even more significant 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 how to make it flexible or if that flexibility will be ever needed. | ||
| + | |||
| + | " | ||
| + | |||
| + | 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, | ||
| + | * 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. | ||
| + | * Avoid numerous classes and methods | ||
| + | * 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 | ||
| + | |||
| + | 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, | ||
| + | |||
| + | 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 than to model and mirror the real-world behavior, which frequently means having more objects and more complicated structures. Nevertheless, | ||
| + | |||
| + | ==== 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.1762287462.txt.gz · Last modified: by ivanblair7
