Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Murphy's Law (ML)
principles:murphy_s_law

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
principles:murphy_s_law [2020-10-12 12:41] – old revision restored (2013-02-12 13:34) 159.69.186.191principles:murphy_s_law [2020-10-12 20:32] – old revision restored (2013-01-16 13:53) 159.69.186.191
Line 23: Line 23:
 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.
  
-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 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.
- +
-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 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.+
  
  
Line 73: Line 71:
   * [[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. 
  
 ==== Contrary Principles ==== ==== Contrary Principles ====
Line 81: Line 78:
 ==== Complementary Principles ==== ==== Complementary Principles ====
  
-  * **[[Fail Fast]] (FF)**: Sometimes it is impossible to actually prevent an error. In such a case it is advisable to fail fast so the error is recognized early.+  * **[[Fail Fast]] (FF)**: Sometimes it is impossible to actually prevent an error. In such a case it is advisable to fail fast to the mistake is recognized early.
  
  
Line 149: Line 146:
 Note that the typecast is rather a symptom than the actual problem here. The problem is, that the ''List'' interface is not generic and the symptom is the typecast. The reason for this flaw is, that the ''List'' interface predates the introduction of generics in Java. Note that the typecast is rather a symptom than the actual problem here. The problem is, that the ''List'' interface is not generic and the symptom is the typecast. The reason for this flaw is, that the ''List'' interface predates the introduction of generics in Java.
  
-==== Example 3: Date, Mutability/Aliasing ==== 
- 
-In Java the classes [[http://docs.oracle.com/javase/7/docs/api/java/util/Date.html|''Date'']] as well as the newer [[http://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html|''Calendar'']] are mutable which means the reference semantics of Java objects may cause unintended alternations of date values. Eventually someone will copy the reference to a date object instead of copying the object itself, which is usually a mistake when programming with dates. 
- 
-<code java> 
-Date date1 = new Date(2013, 01, 16); 
-Date date2 = date1; 
-System.out.println(date1); // Sun Feb 16 00:00:00 CET 3913 
-System.out.println(date2); // Sun Feb 16 00:00:00 CET 3913 
-date1.setMonth(2); 
-System.out.println(date1); // Sun Mar 16 00:00:00 CET 3913 
-System.out.println(date2); // Sun Mar 16 00:00:00 CET 3913 
-</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. 
- 
-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. 
  
 ===== Description Status ===== ===== Description Status =====
principles/murphy_s_law.txt · Last modified: 2021-10-20 21:18 by christian