principles:keep_it_simple_stupid
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| principles:keep_it_simple_stupid [2025-11-18 16:15] – created veronicamcnally | principles:keep_it_simple_stupid [2025-11-25 10:53] (current) – old revision restored (2021-10-20 21:09) christian | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Like the candidates of this presidential campaign go from city to city teaching and preaching what they' | + | ====== Keep It Simple Stupid (KISS) ====== |
| - | We all choose businesses or services because of seemingly inconsequential details. Such as clean bathrooms at simple . restaurant or becoming given water in bottles while your vehicle is being serviced are small details but produce an troublesome belief. Some of those small details keep you time or money, or simply make you're feeling better. It's in the facts that elevate one business above another. | + | ===== Variations and Alternative Names ===== |
| - | It basically Christmas for scammers | + | * (Rule of) Simplicity |
| + | * KISS may also mean "Keep it short and simple", | ||
| - | A C.O. knows how to adjust the spine like a chiropractor, nonetheless they don't assume | + | **Remarks**: |
| - | Of course, you can't simply expect a job to fall into your lap without any effort. Every one of these healthcare jobs will require some training, and faster that beginning from it, far better off you will be. After all, this economy will not wait it is possible to pick up that get. Start training today! | ||
| - | Since employers do lose some tax advantages in this particular proposal, I suggest we allow them to convert those tax advantages for increase with your Acupuncture clinic pay-scale. Each of these suggested changes would create additional jobs far better salaries. | + | ===== Context ===== |
| - | Submit your own to online search engine directories. Don't overlook professional compensation search engines; they may reach a market market the actual reason ideal for the purpose your site has provide. You can also post comments on different blogs and insert objective into the comment. Particular you write something that's useful to avoid Osteopathic clinic looking like those awful spammers. A long way to find these blogs is by typing a keyword of yours in a search engine like Google and then typing "post comment" | + | * [[contexts:Object-Oriented Design]] |
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| - | It appears that abortions will definitely be covered with tax Osteopathic clinic dollars. This has been up against the law until now. What other questionable services (sex change operations, botox injections, etc) will taxpayers by on the hook for? | + | ===== Principle Statement ===== |
| - | Now, companies that are sought after have to focus extensively during the day. They provide services via phone, email, chat, fax, therefore on. All these different mediums allowed them to take proper their clients easily and conveniently. Besides that, there' | + | A simple solution is better than a complex one, even if the solution looks stupid. |
| - | The new roots of your healthcare system must be based on what the public wants - not what our misguided politicians want. Uproot U.S. Healthcare: To Reform U.S. Healthcare, by Deane Waldman, MD MBA, is an efficient and informative read even a real eye-opener to people who believe how the general public has no say as to what happens to your healthcare software program. | ||
| - | A Defense.O. knows how alter the spine like a chiropractor, | + | ===== Description ===== |
| - | If there isn't any so many millions of men and women without [[https:// | + | The KISS principle is about striving for simplicity. Modern programming languages, frameworks |
| - | As the healthcare reporting system runs using a normal PC, installation | + | A solution that follows |
| - | With all the hoopla during | + | 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 | ||
| + | |||
| + | 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 | ||
| + | |||
| + | * 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 | ||
| + | * 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, | ||
| + | |||
| + | 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 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.1763478918.txt.gz · Last modified: by veronicamcnally
