The Left Field

Better regulation through software

There is a lot of talk these days about regulation, especially the kind intended to control the activities of financial organizations. I have a big problem with regulation. I am far from being alone obviously, but most folks have problems with it from a political spectrum perspective. More regulation/less regulation, big government/small government, that sort of thing. That is not the problem I am referring to here.

My problem is that I don't like the fact that regulations are written in human language. Human language, as you may have noticed, is a veritable bottomless pit of ambiguity. I deal with this ambiguity every day. Most of the time, in the form of software specifications.

It seems to me that the problem of regulation and the problem of software specification are really the same problem. In both cases we are attempting to create watertight, formal expressions of what the heck it is we want some horribly complicated "machine" to do. That "machine" could be an ERP system that regulates manufacturing activity downtown at the biscuit factory or it could be a watchdog system that regulates commercial activity downtown in some financial district.

In the world of regulation it generally works like this:

1. use language to specify as best you can, what should happen
2. let stuff happen
3. use humans (regulators/judges etc.) to decide if what happened was okay per the language in the regulations
4. Try to improve the language over time by making changes or issuing more regulations, issuing interpretations (e.g. caselaw) or issuing howto's (e.g. guidance notes and "standards")

The software engineering equivalent works like this:

1. use language to specify as best you can, what should happen
2. write software against the language
3. Put that software in a computer and use humans ("users") to decide if what happened was okay per the language in the specifications
4. Improve the software over time to better fit the needs of the users

The similarities and differences are very interesting. In software, we have a more black-and-white interpretation device - at least to get us started. Either the software machine accepts your input, or it does not. If it does not, your input is wrong or the specifications are wrong. One or the other. Once the machine accepts the input and "works" - we end up in a very similar situation to the world of regulation. I.e. someone has to decide if the behavior of the machine is correct per the specifications or not.

But then a very interesting thing happens. In software the "running code" tends to become the de-facto regulator for future iterations. Often-times, the original specifications fade into the background. To find out whether some input is legal or not, you try it against the reference implementation. Is the syntax or behavior of this piece of Python code valid? Well, to find out you need to do two things.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world