Murphy’s Law

Welcome to the fourth issue of β€œIntractable Problems”, a column designed to challenge and stimulate your thinking skills. In this issue we take a close look at language, at least in the sense of assessing our collective wisdom at understanding computer projects.

Are you familiar with Murphy’s Law? You know, this is the colloquial statement that says that, left to themselves, things tend to go from bad to worse, or what can go wrong will. I would like to look at a few similar gems of wisdom to try and understand how they apply to our work. Let’s begin by listing some laws.

Manly’s Maxim: Logic is a systematic method of coming to the wrong conclusion with confidence.

Murphy’s Corollary: It is impossible to make anything foolproof because fools are so ingenious.

Quantized Revision of Murphy’s Law: Everything goes wrong at once.

Scott’s Second Law: When an error has been detected and corrected, it will be found to have been correct in the first place.

Shaw’s Principle: Build a system that even a fool can use, and only a fool will want to use it.

Rule of Accuracy: When working towards the solution of a problem, it always helps if you know the answer.

Hawkin’s Theory of Progress: Progress does not consist of replacing a theory that is wrong with one that is right; it consists of replacing a theory that is wrong with one that is more subtly wrong.

We follow with some various truths.

  1. Nature sides with the hidden flaw.
  2. Interchangeable parts won’t.
  3. Inside every small problem is a large problem struggling to get out.
  4. Spend sufficient time confirming the need and the need will disappear.
  5. Never attribute to malice that which is adequately explained by stupidity.

Lastly, let’s look at the Laws of Computer Programming:

  1. Any given program, when running, is obsolete.
  2. Any given program costs more and takes longer.
  3. If a program is useful, it will have to be changed.
  4. If a program is useless, it will have to be documented.
  5. Any program expands to fill available memory.
  6. The value of a program is proportional to the weight of its output.
  7. Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.
  8. Any non-trivial program contains at least one bug.
  9. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
  10. Adding manpower to a late software project makes it later.

If any of you have any insight into the inner meaning behind all this, please enlighten me.

In the next issue we will have a critical look at problem solving skills, perhaps more appropriately entitled β€œThe Black Art of Fuzzy Logic.”