Explorations

“No battle plan survives contact with the enemy”

Recall Heinlein’s Razor:

Never attribute to malice that which can be adequately explained by stupidity.

Now, M Simon proposes a correlary:

Never attribute to malice alone that which can be attributed to malice and stupidity.

People are willing to do almost anything to improve a bad situation — except change.

Heinlein’s (sometimes “Hanlon’s”, see Wikipedia) Razor:

Never attribute to malice that which can be adequately explained by stupidity.

But note that most conspiracists are also stupid.

It’s legendary how difficult it can be to herd cats. I have observed, however, that it can be possible to convince a bunch of cats to chase the same mouse.

(Update: “Chase”, dammit. How many times did I read that over and not see the typo until now?)

If you see something stupid, always ask “Is this really stupid? What would make this the smartest possible choice under the circumstances? How is this the most rewarding option of all?”

Many times you’ll find that stupid people are smarter than you think.

The tests are not completed until the prototype is destroyed. — G. Harry Stine

I have often heard it said that any concept, no matter how complicated, can be explained to an interested and motivated 15 year old — if only you understand it yourself.

There is a corollary I think people forget, however: if someone attempts to explain something, and doesn’t succeed, there can only be one of two reasons:

• the explainer doesn’t actually understand what they’re saying, or,
• the explainer would prefer you not to understand what they’re saying.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Jargon File

In the computer business, this is often stated as “if an organization with four groups designs a compiler, it will be a four-pass compiler.”

Here’s an interesting observation: this is a necessary condition. If an organization is big enough to have four groups, then the groups will need to have limited interfaces between them, because otherwise you run into the issue of complexity of communications among all the individuals.[1] This leads to defining an interface, a “separation of concerns” between groups, and the design will then necessarily have interfaces at the same points as the organization producing it.

1. See, for example, the discussion of Brooks’ Law in The Mythical Man Month. Fred Brooks makes the observation that the number of communications paths among team members grows as O(n²), which leads to the observation that in most cases, adding team members means adding quadratically more communication per additional team member. Thus, adding more team members rapidly yields diminishing returns; in a late project, these diminishing returns can overwhelm the additional effort contributed by the new team member. [↩]

One must never precede any maneuver by a comment more predictive than, “Watch this!” — Sanjeev.net Murphy’s Laws Archive