Differences

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

--- principles:keep_it_simple_stupid [2020-10-12 14:37] – old revision restored (2013-03-24 18:56) 159.69.186.191
+++ principles:keep_it_simple_stupid [2020-10-12 20:33] – old revision restored (2013-03-22 15:32) 159.69.186.191
@@ Line 73: / Line 73: @@
   - Simpler solutions are faster to implement.
   - Simpler solutions yield less 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 are easier to maintain, i.e. detecting and correcting defects is effective and efficient.
   - Simpler solutions yield more reliable software, i.e. less defects show up after releasing the software.
@@ Line 80: / Line 80: @@
 Hypothesis 1 can be regarded true by definition. If the solution cannot be implemented fast, 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]]//)).
+Though hypotheses 2 and 3 are not true by definition but they can be regarded intuitively clear. There is only few scientific research concerning these questions directly. As a specific aspect of complexity, complexity through deep inheritance relations is known to reduce effectiveness and efficiency of maintenance. There are controlled experiments showing this((John Daly, Andrew Brooks, James Miller, Marc Roper and Murray Wood: //An Empirical Study Evaluating Depth of Inheritance on the Maintainability of Object-Oriented Software//))((Barbara Unger and Lutz Prechelt: //The Impact of Inheritance Depth on Maintenance Tasks//)). On the other hand these results are limited as there may be many factors which are neglected by the experiment. Most notably in these experiments maintenance tasks where carried out on systems with artificially constructed inheritance hierarchies. Typically there are good ways and bad ways of using inheritance. And rarely there are several equally good solutions for the same problem only differing in the depth of inheritance. So there is some evidence but no "proof" that deep inheritance hampers maintenance.
-Furthermore software cost estimation techniques are partly based on complexity judgments((Barry W. Boehm: //Software Engineering Economics//, IEEE)). So complexity---although this normally relates the complexity of the problem and not to the complexity of the solution---is a known cost factor which may be accounted to maintenance.
+Furthermore software cost estimation techniques are partly based on complexity judgments((Barry W. Boehm: //Software Engineering Economics//, IEEE)). So complexity---although this normally relates the complexity of the problem and not to the complexity of the solution---is a known cost factor.
 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//, p. 168pp.)). Assuming cyclomatic complexity correctly depicts the complexity of a module, reliability should not the reason for applying KISS.