• Design for Errors¹⁾

• Object-Oriented Design

Whatever can go wrong, will go wrong. So a solution is better the less possibilities there are for something to go wrong.

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 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.

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.

Systems are built and used by humans. And as humans always will make mistakes, there always will be some possibilities for a certain mistake. So if some mistake is possible, eventually there will be someone who makes this mistake. This applies likewise to system design, implementation, verification, maintenance and use as all these tasks are (partly) carried out by humans.

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 is a very general principle so there is a large variety of possible strategies to adhere more to this principle largely depending on the given design problem:

• 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)
• Use automatic testing to find defects
• Avoid duplication and manual tasks, so necessary changes are not forgotten (see Don't Repeat Yourself)
• Use polymorphism instead of repeated switch statements
• Use the same mechanisms wherever reasonably possible (see Uniformity Principle)
• Use consistent naming and models throughout the design (see Model Principle)
• …

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 ²⁾ and Wikipedia.

• Accepted The principle is widely known and it's validity is assumed. Nevertheless sometimes it is rather used as a kind of joke instead of an design advice. See for example Jargon File: Murphy's Law

• 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.
• 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.

• 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.

• 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.

Incomplete

• Murphy's Law
• MurphysLaw
• murphys-laws.com