This is an old revision of the document!
Table of Contents
Murphy's Law (ML)
Variants and Alternative Names
- Design for Errors1)
Context
Principle Statement
Whatever can go wrong, will go wrong. So a solution is better the less possibilities there are for something to go wrong.
Description
Although often cited like that, Murphy's Law actually is not a fatalistic comment stating “that life is unfair”. Rather it is 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.
Rationale
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.
Strategies
This is a very general principle so there is a large variety of possible strategies to adhere more to this principle:
- 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. (see Don't Repeat Yourself)
- Use polymorphism instead of repeated switch statements.
- …
Origin
“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.”
