The importance of context

I am about to display my programming roots. History alert.
In a far off kingdom computers were made by an all powerful company - called IBM. IBM had the most magnificent Operating System, inventively called "OS". This operating system came in a number of dialects (OS/MFT, OS/MVT - eventually morphing to SVS and MVS before becoming Z/OS). The people marveled. What wondrous naming! But I digress.
To get work done on these behemoths - especially batch work, a special dialect, conjured from an unfettered imagination, was created. This dialect - whose name is uttered in hushed tones was "JCL" or "Job Control Language".
JCL provided the context under which jobs are scheduled, programs executed, files were created or disposed (disposition processing). The JCL sorcerers were much in demand in the early devops days.
IBM provided a series of utilities for doing useful tasks to files, jobs, etc. But the most cunning, the most fiendish of all was the well named IEFBR14. Befor describing its inner workings in gory detail, we need to step back and look at the JCL some more.
When a program executes in an "OS" environment, it can indicate to the environment that it has been successful or has failed. This is done using a "Return Code". Nothing strange there - at least not on the surface. However the return code value can be used to control what happens next. For example if a program is supposed to create a file, but somehow aborts, one can through the magic of JCL say that the system is to delete the file. If the program is successful, one could tell the system that the file is to be kept, etc.
Genius.
So where was this return code kept? In a general pirpose "register" called register15 (R15) for short. Why there? Because R15 had a use at the beginning of the program and not much thereafter. When a program executes, R15 contains the memory address of the entry point of the program (well almost, but that's close enough for government work). So the one value one would not expect in R15 was 0. It was thus important to explicitly set R15 to the proper value before the program terminated. Other wise the return code would be the starting address of the program. Awkward.
Now lets look at the program IEFBR14. It's genius was that it did absolutely nothing. It started and immediately exited. It used to consist of a single machine instruction. The instruction (BR 14) that causes the program to terminate (actually branch to the address held in register 14, which by convention at the end of the program is back to the OS). When the program terminates, disposition - as controlled by JCL takes over. Since the return code value was random and arbitrary (except its value is always nonzero and evenly divisible by 4), no exection of IEFBR14 ever executed cleanly. Thus messing up disposition processing.
To end a long story, the size of the program IEFBR14 was doubled. From one instruction to 2. First off R15 was cleared to zero - at least its value is now predictable. And then the BR14 instruction executes. Victory!
The important lesson, however, is that you cannot ignore the context in which your systems (in this case a simple program) execute. The environmentals are key.

Law is the requirements specification for the system of being a resident

Our (US) government uses taxation and tax relief as a way of enacting all sorts of public policy legislation. For example, we have a way of paying medical bills through the use of a tax relieved account. Sounds great doesn't it. I put so much aside every month into an account (a Flexible Spending Account or some such TLA). Then when I have to pay for some procedure (like new glasses, eye exams, dental stuff, etc.) that is somehow not covered by my healthcare payment system (aka "Insurance" which it patently isn't), I use money from this tax relieved account. Sounds great - I'll have some of that think the politicians who prepared the bill and sold it to banks, lobbyists, lawyers and eventually the people.

However it doesn't quite work! On every occasion that I have used the account this year I get a letter from the account sdministrators that essentially says, "I don't believe that you have used this for a legitimate purpose, so please provide suitable documentation".
I bought eyeglasses and lenses, I had my teeth cleaned. The credit card receipts showed where I spent the money, but not on what. So, I now have to go through find the receipts with the actual things I paid for on them, submit them to the processing company - who have presumably got a bunch of employees doing low value work verifying that I haven't somehow spent the money on something not covered (toothpaste for $185  at the dentist?, Glasses cleaner for $350 at the optomerist?)

When our lawmakers specify the "system", they don't seem to take the possibility of fraud into consideration. The initial assumption is all unicorns and rainbows. It is assumed that people won't cheat the system, that the happy path is the only path....

That thinking, however, fails to take into account the inventiveness of part of the population. That part of the population that will attempt to use the system in a way it was not designed to be used, for personal gain. So the cycle seems to be.

1. Create legislation that makes things look really rosy for the populace, vested interests, lawyers, etc.
2. Roll the "system" that embodies that legislation out
3. Be shocked that there is abuse
4. Place layer upon layer of administrative/bureaucratic overhead to prevent the potential abuse
5. Ignore fraudsters
6. Proclaim that jobs have been created
7. Rinse and repeat.

If we can't be sure that a relatively small system will behave properly - even with iterative development methods, what hope is there for the waterfall approach in the legislative process?

A rant against 1:1

Everey now and again, I get really annoyed with sites that assume you have only one of something. "Please enter your email address" is a common request - except that I have several, and would like to have the opportunity to use any of them as my login id. After all they are each unique. Tripit.com does it right. Many other sites do it wrong. This posting from Robert Scoble illustrates the kind of muddy thinking. Apple making the assumption that there is one credit card.
Years ago, I used Plaxo. However the geniuses behind that didn't think I might have more than 1 email address, more than 1 set of followers, so I would get suggestions from them to follow people I was already following.
In the world there are very few 1:1 correspondences that are timeless. So any time a system assumes that there is a pair of things that are in absolute 1:1 correspondence, I am mightily suspicious.
There are 2 interesting cases to ponder:
1:1 at a time and 1:1 over time.
1:1 at a time, I get. However there have to be rules/policies/processes or whatever to change to a new one. But even those are suspicious because we may have to account for the zero case. And it usually isn't bilaterally 1:1.
1:1 over time is much harder. If it isn't possible for two things to exist independently of each other (for each one there is always exactly one of the other), then we have to question why they are not combined. By the way there are often good technical reasons, but maybe not so many good business or policy reasons.
So a word to the wise, when someone tells you there is a 1:1 correspondence, then they may be talki8ng about a single world view and that you should at least explore the alternatives lest you be trapped in an expensive rethinking process.