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.