Differences

This shows you the differences between two versions of the page.

--- principles:keep_it_simple_stupid [2016-09-04 01:00] – [Rationale] 5.12.30.152
+++ principles:keep_it_simple_stupid [2020-01-20 17:26] – [Context] 193.158.100.19
@@ Line 26: / Line 26: @@
 A solution that follows the KISS principle might look boring or even "stupid" but simple and understandable. The KISS principle states that there is no value in a solution being "clever" but in one being easily understandable.
-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 in using them.
+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 =====
@@ Line 39: / Line 37: @@
 "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." - Refactoring To Patterns - Joshua Kerievsky.
-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 the to follow the
+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": (1. Don't, 2. Don't... Yet, 3. Profile before optimizing), which make sense: to optimize only the code with performance problems. (First author: Michael A. Jackson)
@@ Line 80: / Line 78: @@
 The following hypotheses can be stated:
   - Simpler solutions are faster to implement.
-  - Simpler solutions yield less implementation faults (which reduces testing effort).
+  - 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. less defects show up after releasing the software.
+  - 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 can be regarded true by definition. If the solution cannot be implemented fast, 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: //[[http://dl.acm.org/citation.cfm?id=62073|System Structure and Software Maintenance Performance]]//)) a system was improved in two steps resulting in three variants of the same system. Several metrics show that the improvements reduced complexity. 36 programmers with varying experience conducted three different maintenance tasks and their performance was measured. The results indicate that the improvements also improved maintainability. Several other studies support the correlation between complexity and maintainability((Chris F. Kemerer: //[[http://link.springer.com/article/10.1007%2FBF02249043?LI=true|Software complexity and software maintenance: A survey of empirical research]]//)).