Extracted from Rules: Shaping Behavior and Knowledge, by Ronald G. Ross, 2023, 274 pp, https://www.brsolutions.com/rules-shaping-behavior-and-knowledge-book.html

The picture below still makes me a bit queasy. The single rubber band to hold the deck of punch cards together just looks too flimsy to me.

You see, I went to graduate school for computer science classes in the early 1970s.

Aside: If you the reader are younger than 60 and not interested in history, go to "Thought Experiment for Procedural vs. Declarative Specifications" below. (Ah, a notorious 'go to' instruction!)

The Deck History

In those days we used punch cards to specify and execute computer programs. Keeping a deck of punch cards in the right order was a huge 'programming' concern. Drop them on the floor accidentally and you risked spending the entire evening in the computer lab (which happened often anyway, given the slow turnaround of operations).

Those were the days of mainframe computers. Virtually all software development was done in-house, in batch. Jobs were submitted as decks of cards (sometimes quite large) and came back as paper printouts (several hours or even a day later). Often, a job had to be re-run many times to get it right. The outputs took the form of over-sized, folded listings, sometimes inches thick. Those were the days. Not!

So, you went to the lab armed with boxes of the strongest rubber bands you could find and magic markers of different colors to draw diagonal lines across the outer edges of decks. Every student had lived the nightmare of dropping decks, so the following thought experiment really hit home.

Thought Experiment for Procedural vs. Declarative Specifications

I suppose this thought experiment has lost some of its punch over the years (pun intended) since we no longer use physical media to specify programming logic. But you'll get the point anyway. It's still the best analogy I've ever heard to explain the difference between declarative specifications vs. procedural specifications.

Here are the instructions:

1. Write a computer program.


2. Specify each statement on a separate card.


3. Give the deck of cards to operations to execute.


4. Make sure the program runs properly and has no bugs.


5. Take the rubber band(s) off the deck and throw the cards high up in the air.


6. Pick the cards up in random order off the floor (making sure you haven't lost any and they are all right-side up).


7. Give the deck to operations to execute again.


8. Inspect the results.

If the logic still executes properly, it's declarative. If not, it's procedural.

So simple, yet so powerful a test! Here's what it means:

• If the program still works properly, there are no hidden semantics in the logic. The order of presentation of the cards (statements) to the machine for execution makes no difference to the outcome.


• If the program doesn't still work properly, then not all the semantics could be accessed by the machine even after reading the entire deck. Some were hidden 'in-between' the individual cards; that is, implicit in the sequence of instructions.

Aside: Don't mistake logical dependence for sequential dependence. For example, if the calculation of net profit depends on the calculation of gross income, obviously gross income has to be calculated first, even if not the first statement presented. But a machine can figure that out, just like a human can, based on the term 'gross income' common to both rules.

In rules for business and government, hidden semantics in rules is never good. Groups and communities of people must share understanding of rules, and they can't do that if meaning is withheld. So, rules for business and government should always be purely declarative. Sequence should never matter!

Separation of Concerns

Let's be very clear here about what I'm saying and what I'm not saying. I'm not saying that instructions and procedures (sequenced sets of instructions) are a bad thing. It goes without saying they're extremely important. How could we live without them!

For example, the only way I could have communicated the thought experiment above effectively was as a procedure. I couldn't have expressed it as rules. And why would I even want to try?! In no way, shape, or form do rules substitute for procedures or processes. Rules simply tell you what results are correct.

Look at it this way. Without actions, procedures, and processes, the state of the world would never change. We obviously don't live in a static world … and couldn't even if we wanted to. Actions, procedures, and processes (transforms) are a fundamental fact of life.

Rules for communities and groups of people serve a different purpose. They never make things happen; they simply express which states of affairs are allowed (desirable) or more importantly, which are not allowed (undesirable). Rules are imposed on actions.

As a consequence, you never want to mix or confuse rules and instructions. You always want to be clear which is which. By 'mix', I specifically mean two things:

• A 'rule' should never call for the execution of an action. If it does, it's not a true rule; it's an instruction and should be treated as such. (Notorious in this regard are 'rules' calling on the infamous CRUD words — create, retrieve, update, delete. These are pure (data) system actions.)


• Even if an individual rule is expressed declaratively, it should never be included as a step in a procedure (set of instructions). Implicitly, including an individual rule at a certain place in a sequenced set of instructions turns the rule into an instruction.

Keeping the distinction between rules (declarative) and instructions (procedural) is an important task for policy interpreters and analysts. Subject matter experts often want to tell you how to do things, so their tendency is to talk procedurally.

How is important, of course. Equally important for groups and communities of people, however, is expressing criteria (rules) for the correctness of what happens. Keep them distinct! Instructions are about the right things to do to get something done; rules are about getting things right no matter how they are done.

Conditional Instructions

Let's look at some additional examples.

Sign Posted on Glass Box Containing an Ax: In case of fire, break glass.

This statement is conditional ("in case of fire") but gives an instruction ("break glass"). It calls for the execution of an action. It is not a rule. For the same reason, all the following are conditional instructions, not rules:

• If the plastic tears, fix it with duct tape.


• If the game is important to you, jump on the first plane to get there.


• Before the grenade is thrown, remove the safety pin.

A distinctive feature of all instructions, whether conditional or not, is that it makes a difference what order they are evaluated in. Let's suppose instead of just one sign, you see two signs posted near each other:

Sign Posted on Glass Box Containing an Ax: In case of fire, break glass.

Sign Posted near Elevators: In case of fire, exit building using stairs.

Which instruction you act on first makes a big difference. If you perform former first, you will probably exit the building with broken glass on the floor and perhaps an ax in your hand. If you perform the latter instruction first, the glass will likely remain unbroken and the ax where it is. Those states of the world are very different.

Rules should never work that way. Since rules perform no actions, it makes no difference whatsoever what order you (or a machine) read them in. They all apply equally. Collectively, they simply tell you whether the state of the world in between actions is correct — that is, allowed (desirable) or not allowed (undesirable). No small matter!

# # #