Milestone for Mr. Murphy

It's been 60 years since Mr. Murphy was credited with the "law" that bears his name: Whatever can go wrong, will go wrong.

Marcus Dunk wrote a nice tribute to the US Air Force safety engineer in today's Daily Mail:

Born in 1918, Murphy was the eldest of five children and attended the prestigious United States Military Academy, West Point, from which he graduated in 1940. He was immediately commissioned into the army Air Corps, and during the Second World War saw action against the Japanese in China and Burma.

A fine and conscientious pilot who was often described as 'no-nonsense', Murphy decided after the war to involve himself in the technological aspects of aircraft design, and went to work as a research and development officer for the Air Force.

[...]

For Murphy himself, the law and its variations to which he gave his name was the cause of great annoyance. While he preferred to see the law as a principle of good, defensive design - a willingness to be prepared for the worst - he regarded most versions of his Law as 'ridiculous, trivial and erroneous', and said as much before his death in 1990.

Although he may have failed to see the joke, he does have something of a point. While it is easy to label Murphy's Law as the ultimate pessimist's charter, there is an undercurrent of optimism running just beneath the surface of this Law, one that wryly acknowledges that although things will probably go wrong, recognising that fact is the first step in being prepared for when that actually happens. [emphasis added]

As any Scout would say, "Be prepared!"

My cousin Rob's corollary is that simply identifying the "possible" modes of failure reduces the chance of those failures occurring, both during testing and in use.

Dr. W. Edwards Deming, who preached the gospel of statistical process control (SPC), was adamant that you couldn't test quality into a product: it has to be built in. That principle is just as applicable to software projects as widget manufacturing.

For any development project, integration and test (I&T) is the phase where past sins, both technical and managerial, become apparent. Development schedules slip, squeezing testing, while system-of-system design flaws lay undiscovered until the whole product is assembled, leaving no time to recover.

If you expect the piece parts of your software or hardware system to come together smoothly during the I&T phase of your project, you really need to concentrate on identifying the factors that could go wrong during I&T and eliminate or mitigate their risks -- and do it early in the game.

In other words, it's good engineering practice to try and thwart Murphy's Law by eliminating things that can go wrong. Thank you Mr. Murphy!