principles:murphy_s_law
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
principles:murphy_s_law [2013-03-19 16:58] – christian | principles:murphy_s_law [2021-10-20 21:18] (current) – +++ restored and merged +++ christian | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
- | * Design for Errors((Alan M. Davis: //201 Principles | + | * Design for Errors(({{page> |
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
* [[contexts: | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
===== Principle Statement ===== | ===== Principle Statement ===== | ||
Line 17: | Line 19: | ||
===== Description ===== | ===== Description ===== | ||
- | Although often cited like that, Murphy' | + | Although often cited like that, Murphy' |
- | Ideally | + | Ideally, 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 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 " | 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 " | ||
Line 25: | Line 27: | ||
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, | 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, | ||
- | Note that Murphy' | + | Note that Murphy' |
Line 34: | Line 36: | ||
This means the fewer possibilities there are that a mistake is made, the fewer there will be. As mistakes are generally undesirable, | This means the fewer possibilities there are that a mistake is made, the fewer there will be. As mistakes are generally undesirable, | ||
+ | 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 46: | Line 49: | ||
* Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle|UP]]) | * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle|UP]]) | ||
* Use consistent naming and models throughout the design (see [[Model Principle|MP]]) | * Use consistent naming and models throughout the design (see [[Model Principle|MP]]) | ||
- | * Avoid Preconditions and Invariants (see [[Invariant Avoidance Principle]]) | + | * Avoid Preconditions and Invariants (see [[Invariant Avoidance Principle|IAP]]) |
+ | * Use assertions to detect problems early. | ||
* ... | * ... | ||
Line 57: | Line 61: | ||
===== 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 | + | 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 |
Line 65: | Line 69: | ||
/* * [[wiki: | /* * [[wiki: | ||
- | * [[wiki: | + | * [[wiki: |
/* * [[wiki: | /* * [[wiki: | ||
+ | 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 76: | Line 81: | ||
==== Specializations ==== | ==== Specializations ==== | ||
- | * [[Don' | + | * [[Don' |
* [[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 t 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 " | + | * **[[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 " |
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
Line 113: | Line 118: | ||
replaceAll(String pattern, String replacement) | replaceAll(String pattern, String replacement) | ||
</ | </ | ||
- | This is less error prone. When for example a call to '' | + | This is less error prone. When for example a call to '' |
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 " | 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 " | ||
Line 160: | 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); | + | System.out.println(date1); |
- | System.out.println(date2); | + | System.out.println(date2); |
date1.setMonth(2); | date1.setMonth(2); | ||
- | System.out.println(date1); | + | System.out.println(date1); |
- | System.out.println(date2); | + | System.out.println(date2); |
</ | </ | ||
- | 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 " |
Because of these and several other flaws in the design of the Java date API, most of the methods in '' | Because of these and several other flaws in the design of the Java date API, most of the methods in '' | ||
Line 185: | Line 190: | ||
* [[wiki> | * [[wiki> | ||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/murphy_s_law.1363708731.txt.gz · Last modified: 2013-05-20 12:46 (external edit)