F**king up Policy and Mechanism

In countless situations the failure to distinguish and take advantage of separating policy vs mechanism in engineering has resulted in irresponsible disaster. Let's enumerate the scenarios:

1. Good mechanism, lousy policy
2. Lousy mechanism, good policy
3. Lousy mechanism and policy

Scenario 1 happens when you have good engineers building the system, but lousy managers making irresponsible policy decisions.
Scenario 2 happens when you have lousy engineers but the managers have lucked out in making the right policy decisions.
Scenario 3 happens when the people just don't know WTF they are doing.

Countless computer science texts try to impress this notion on those willing to read and understand them. Unfortunately, in software there are more people involved in building software systems who have never read these texts than those that have. And when the guys who understand that distinction try to explain it to those that haven't, we see the "eyes glazing over effect" play out.

Maybe its the way has been explained. For example, here's Andy Tenenbaum's dry take on it.
I usually use the door lock analogy, where the door locks are the mechanism, and the policy is deciding who gets the keys and defining when the locks are engaged or not. Rather straightfoward, no? Then why the continual failure? I'm tending to believe that scenario 1 is the main culprit here, where managers are setting bad policies that result in broken systems. Maybe the manager is marketing guy who used to be a sales guy and worked their way up but have a non-technical background, or do have a technical background but not a firm grasp of a newer technology. Whatever. Understanding policy vs. mechanism is the hallmark of a good manager. Failure for a manager to understand this is incompetence.

So there are those of you in the audience that say, but those managers have a bigger picture in view, and those so-called "bad" policies may indeed be the right one to take. To which I call bullshit. At least 99% of the time.

Starting out in fits ...

... and starts. Or stops. But maybe its my old age thats making posting here erratic. Got to start somewhere. So what is this site about? In part its our itch to scratch where in solving an engineering problem there's always some guy somewhere who says, "oh we (or that) problem got solved years ago, but does anybody remember? Nnnnnnoooooo!" and then starts getting into a grumpy old man rant, while everyone else in the room looks at him blankly and pauses, and then go on to reinvent the wheel.

This happens in a lot of problem domains. This blog wants to give that grumpy old engineer a voice.
Welcome.

First post

This is the first post.