User Tools

Site Tools


principles:murphy_s_law

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
principles:murphy_s_law [2021-09-02 10:43]
65.21.179.175 old revision restored (2021-05-11 22:12)
principles:murphy_s_law [2021-10-20 21:18] (current)
christian +++ restored and merged +++
Line 3: Line 3:
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
  
-  * Design for Errors((Alan M. Davis//201 Principles of Software Development//))+  * Design for Errors(({{page>resources:201 Principles#reference}}))
  
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
   * [[contexts:Object-Oriented Design]]    * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:User Interface Design]]  
 +  * [[contexts:Implementation]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 17: Line 19:
 ===== Description ===== ===== Description =====
  
-Although often cited like that, Murphy's Law actually is not a fatalistic comment stating "that life is unfair". Rather it is (or at least can be seen as) an engineering advice to design everything in a way that avoids wrong usage. This applies to everything that is engineered in some way and in particular also to all kinds of [[glossary:modules]], (user) interfaces and systems.+Although often cited like that, Murphy's Law actually is not a fatalistic comment stating "that life is unfair". Rather it is (or at least can be seen as) engineering advice to design everything in a way that avoids wrong usage. This applies to everything that is engineered in some way and in particular also to all kinds of [[glossary:modules]], (user) interfaces and systems.
  
-Ideally an incorrect usage is strictly impossible. For example this is the case when the compiler will stop with an error if a certain mistake is made. And in case of user interface design, a design is better when the user cannot make incorrect inputs as the given controls won't let him.+Ideallyincorrect usage is strictly impossible. For examplethis is the case when the compiler will stop with an error if a certain mistake is made. And in the case of user interface design, a design is better when the user cannot make incorrect inputs as the given controls won't let him.
  
 It is not always possible to design a system in such a way. But as systems are built and used by humans, one should strive for such "fool-proof" designs. It is not always possible to design a system in such a way. But as systems are built and used by humans, one should strive for such "fool-proof" designs.
  
-Note that Murphy's law also applies to every chunk of code. According to the paw the programmer will make mistakes while implementing the system. So it is better to implement a simple design, as this will have fewer possibilities to make implementation mistakes. Furthermore code is maintained. Bugfixes will be necessary present functionality will be changed and enhanced, so every piece of code will potentially be touched in future. So a design is better the fewer possibilities there are to introduce faults while doing maintenance work.+There are different kinds of possible errors that can and according to ML eventually will occur in some way: Replicated data can get out of sync, invariants can be broken, preconditions can be violated, interfaces can be misunderstood, parameters can be given in the wrong order, typos can occur, values can be mixed up, etc. 
 + 
 +Note that Murphy's law also applies to every chunk of code. According to the law the programmer will make mistakes while implementing the system. So it is better to implement a simple design, as this will have fewer possibilities to make implementation mistakes. Furthermore code is maintained. Bugfixes will be necessarypresent functionality will be changed and enhanced, so every piece of code will potentially be touched in the future. So a design is better the fewer possibilities there are to introduce faults while doing maintenance work.
  
  
Line 32: Line 36:
 This means the fewer possibilities there are that a mistake is made, the fewer there will be. As mistakes are generally undesirable, a design is better when there are fewer possibilities for something to go wrong. This means the fewer possibilities there are that a mistake is made, the fewer there will be. As mistakes are generally undesirable, a design is better when there are fewer possibilities for something to go wrong.
  
 +Note that ML does //not// claim that everything constantly fails unless there is no possibility to do so. It simply says that statistically in the long run a system will fail if it can.
  
 ===== Strategies ===== ===== Strategies =====
Line 38: Line 43:
  
   * Make use of static typing, so the compiler will report faults   * Make use of static typing, so the compiler will report faults
-  * Make the design simple, so there will be fewer implementation defects (see [[Keep It Simple Stupid]])+  * Make the design simple, so there will be fewer implementation defects (see [[Keep It Simple Stupid|KISS]])
   * Use automatic testing to find defects   * Use automatic testing to find defects
-  * Avoid duplication and manual tasks, so necessary changes are not forgotten (see [[Don't Repeat Yourself]])+  * Avoid duplication and manual tasks, so necessary changes are not forgotten (see [[Don't Repeat Yourself|DRY]])
   * Use polymorphism instead of repeated switch statements   * Use polymorphism instead of repeated switch statements
-  * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle]]) +  * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle|UP]]) 
-  * Use consistent naming and models throughout the design (see [[Model Principle]])+  * Use consistent naming and models throughout the design (see [[Model Principle|MP]]) 
 +  * Avoid Preconditions and Invariants (see [[Invariant Avoidance Principle|IAP]]) 
 +  * Use assertions to detect problems early.
   * ...   * ...
 +
 +
 +===== Caveats =====
 +
 +See section [[#contrary principles]].
  
  
 ===== Origin ===== ===== Origin =====
  
-The exact wording and who exactly coined the term, remains unknown. Nevertheless it can be stated that its origin is an experiment with a rocket sled conducted by Edward A. Murphy and John Paul Stapp. During this experiment some sensors have been wired incorrectly. A more accurate quote might read something like this: "If there's more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way." A more detailed version of the history of the experiment and the law can be found in ((Nick T. Spark: [[http://www.improb.com/airchives/paperair/volume9/v9i5/murphy/murphy0.html|The Fastest Man on Earth]]. In: Annals of Improbable Research)) and Wikipedia.+The exact wording and who exactly coined the term, remains unknown. Neverthelessit can be stated that its origin is an experiment with a rocket sled conducted by Edward A. Murphy and John Paul Stapp. During this experimentsome sensors had been wired incorrectly. A more accurate quote might read something like this: "If there's more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way." A more detailed version of the history of the experiment and the law can be found in ((Nick T. Spark: [[http://www.improb.com/airchives/paperair/volume9/v9i5/murphy/murphy0.html|The Fastest Man on Earth]]. In: Annals of Improbable Research)) and Wikipedia.
  
  
Line 57: Line 69:
 /*  * [[wiki:Examined]]*/ /*  * [[wiki:Examined]]*/
  
-  * [[wiki:Accepted]] The principle is widely known and it'validity is assumed. Nevertheless sometimes it is rather used as a kind of joke instead of an design advice. See for example Jargon File: //[[http://www.catb.org/jargon/html/M/Murphys-Law.html|Murphy's Law]]//+  * [[wiki:Accepted]] The principle is widely known and its validity is assumed. Nevertheless sometimes it is rather used as a kind of joke instead of as design advice. See for example Jargon File: //[[http://www.catb.org/jargon/html/M/Murphys-Law.html|Murphy's Law]]//
  
 /*  * [[wiki:Questioned]]*/ /*  * [[wiki:Questioned]]*/
  
 +Furthermore every defect in any system is a manifestation of ML. If there is a fault then obviously something went wrong. The correlation between the number of possibilities for introducing defects and the actual defect count can be regarded trivially intuitive.
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
Line 68: Line 81:
 ==== Specializations ==== ==== Specializations ====
  
-  * [[Don't Repeat Yourself]] (DRY): Duplication is a typical example for error possibilities. In case of a change, all instances of a duplicated piece of information have to be changed accordingly. So there is always the possibility to forget to change one of the duplicates. DRY is the application of ML to duplication.+  * [[Don't Repeat Yourself]] (DRY): Duplication is a typical example of error possibilities. In case of a change, all instances of a duplicated piece of information have to be changed accordingly. So there is always the possibility to forget to change one of the duplicates. DRY is the application of ML to duplication.
   * [[Easy to Use and Hard to Misuse]] (EUHM): Because of ML an interface should be crafted so it is easy to use and hard to misuse. EUHM is the application of ML to interfaces.   * [[Easy to Use and Hard to Misuse]] (EUHM): Because of ML an interface should be crafted so it is easy to use and hard to misuse. EUHM is the application of ML to interfaces.
   * [[Uniformity Principle]] (UP): A typical source of mistakes are differences. If similar things work similarly, they are more understandable. But if there are subtle differences in how things work, it is likely that someone will make the mistake to mix this up.   * [[Uniformity Principle]] (UP): A typical source of mistakes are differences. If similar things work similarly, they are more understandable. But if there are subtle differences in how things work, it is likely that someone will make the mistake to mix this up.
-  * [[Invariant Avoidance Principle]] (IAP): Invariants are statements that have be true in order to keep a module in a consistent state. ML states that eventually an invariant will be broken resulting in a hard to detect defect. IAP states that invariants should therefore be avoided. So IAP is the application of ML to invariants.+  * [[Invariant Avoidance Principle]] (IAP): Invariants are statements that have to be true in order to keep a module in a consistent state. ML states that eventually an invariant will be broken resulting in a hard to detect defect. IAP states that invariants should therefore be avoided. So IAP is the application of ML to invariants. 
 ==== Contrary Principles ==== ==== Contrary Principles ====
  
-  * **[[Keep It Simple Stupid]] (KISS)**: On the one hand a simpler design is less prone to implementation errors. In this aspect KISS is similar to ML. On the other hand it is sometimes more complicated to make a design "fool-proof" so usage and maintenance mistakes are prevented. In this aspect KISS is rather a contrary principle. Both applies at the same time so a tradeoff has to be made whether correct implementation or correct usage and maintenance are more important in the given case. This means, it is necessary to consider KISS in addition to ML in order to find a suitable compromise.+  * **[[Keep It Simple Stupid]] (KISS)**: On the one hand a simpler design is less prone to implementation errors. In this aspectKISS is similar to ML. On the other handit is sometimes more complicated to make a design "fool-proof" so usage and maintenance mistakes are prevented. In this aspect KISS is rather a contrary principle. Both apply at the same time so a tradeoff has to be made whether correct implementation or correct usage and maintenance are more important in the given case. This means, it is necessary to consider KISS in addition to ML in order to find a suitable compromise. See [[#example 1: parameters]].
  
 ==== Complementary Principles ==== ==== Complementary Principles ====
Line 86: Line 100:
  
  
-===== Example =====+===== Examples =====
  
 ==== Example 1: Parameters ==== ==== Example 1: Parameters ====
Line 94: Line 108:
 The following method signatures are a bad choice: The following method signatures are a bad choice:
 <code java> <code java>
-replaceFirst(String pattern, string replacement) +replaceFirst(String pattern, String replacement) 
-replaceAll(String replacement, string pattern)+replaceAll(String replacement, String pattern)
 </code> </code>
 Eventually someone will mix up the order of the parameters leading to a fault in the software which is not detectable by the compiler.  Eventually someone will mix up the order of the parameters leading to a fault in the software which is not detectable by the compiler. 
Line 101: Line 115:
 So it is better to make parameter lists consistent: So it is better to make parameter lists consistent:
 <code java> <code java>
-replaceFirst(String pattern, string replacement) +replaceFirst(String pattern, String replacement) 
-replaceAll(String pattern, string replacement)+replaceAll(String pattern, String replacement)
 </code> </code>
-This is less error prone. When for example a call to ''replaceFirst()'' is replaced by a call to ''replaceAll()'', one cannot forget to exchange the parameters anymore. This is how is is done in the [[http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replaceFirst(java.lang.String, java.lang.String)|Java API]].+This is less error prone. When for example a call to ''replaceFirst()'' is replaced by a call to ''replaceAll()'', one cannot forget to exchange the parameters anymore. This is how it is done in the [[http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replaceFirst(java.lang.String, java.lang.String)|Java API]].
  
 But here still one could mix up the two string parameters. Although this is less likely, as having the substring to look for first is "natural", such a mistake is still possible. An alternative would be the following: But here still one could mix up the two string parameters. Although this is less likely, as having the substring to look for first is "natural", such a mistake is still possible. An alternative would be the following:
 <code java> <code java>
-replaceFirst(Pattern pattern, string replacement) +replaceFirst(Pattern pattern, String replacement) 
-replaceAll(Pattern pattern, string replacement)+replaceAll(Pattern pattern, String replacement)
 </code> </code>
 Here both methods expect a ''Pattern'' object instead of a regular expression expressed in a string. Mixing up the parameters is impossible in this case as the compiler would report that error. On the other hand using these methods becomes a bit more complicated:  Here both methods expect a ''Pattern'' object instead of a regular expression expressed in a string. Mixing up the parameters is impossible in this case as the compiler would report that error. On the other hand using these methods becomes a bit more complicated: 
Line 151: Line 165:
  
 <code java> <code java>
-Date date1 = new Date(2013, 01, 16);+Date date1 = new Date(2013, 01, 12);
 Date date2 = date1; Date date2 = date1;
-System.out.println(date1); // Sun Feb 16 00:00:00 CET 3913 +System.out.println(date1); // Sun Feb 12 00:00:00 CET 3913 
-System.out.println(date2); // Sun Feb 16 00:00:00 CET 3913+System.out.println(date2); // Sun Feb 12 00:00:00 CET 3913
 date1.setMonth(2); date1.setMonth(2);
-System.out.println(date1); // Sun Mar 16 00:00:00 CET 3913 +System.out.println(date1); // Sun Mar 12 00:00:00 CET 3913 
-System.out.println(date2); // Sun Mar 16 00:00:00 CET 3913+System.out.println(date2); // Sun Mar 12 00:00:00 CET 3913
 </code> </code>
  
-Furthermore as can be seen in the code above, the month value counterintuitively is zero-based, which results in 1 meaning February. This obviously is another source for mistakes.+Furthermore as can be seen in the code above, the month value counterintuitively is zero-based, which results in 1 meaning February. This obviously is another source for mistakes. Also the order of the parameters can be mixed up easily. And lastly this does not refer to a date in 2013 but to one in 3913! The year value is meant to be "two-digit", so 1900 is added to it. So there are plenty of possibilities for making mistakes. And sooner or later someone will make them.
  
 Because of these and several other flaws in the design of the Java date API, most of the methods in ''Date'' are deprecated and also the newer ''Calendar'' API will be replaced by a [[http://openjdk.java.net/jeps/150|new API]] in Java 8. Because of these and several other flaws in the design of the Java date API, most of the methods in ''Date'' are deprecated and also the newer ''Calendar'' API will be replaced by a [[http://openjdk.java.net/jeps/150|new API]] in Java 8.
Line 176: Line 190:
   * [[wiki>MurphysLaw]]   * [[wiki>MurphysLaw]]
  
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Murphy's Law|talk page]].
principles/murphy_s_law.1630572230.txt.gz · Last modified: 2021-09-02 10:43 by 65.21.179.175