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. Try it against the reference implementation and check with the language reference. You application may be doing something which is officially allowed to vary..but probably not.

Is the behavior of my servlet correct? Try it against the reference implementation (Apache Tomcat) and check with the servlet specification. Your servlet may be doing something which is officially allowed to vary..but probably not.

In the short history of software engineering we have seen tremendous efforts to improve matters in software specifications. To address the disconnect between what is expressed in human language and what software systems actually do when built. We have mathematical formalisms, we have design by contract, we have UML, we have Test Driven Development...

In the much longer history of regulation, we have seen...not so much - at least outside of academia. If the problems are as similar as I have suggested, why has there been so much less innovation in the area of regulation specification? Beats me.

Switching to my minds eye...I see a bank of computers housed in a downtown financial regulator. The machines are running reference implementations of what it means to be a player in regulated industry X. Player strategies are coded up and executed to see if they are valid per the reference implementation of the rules of the game...

Wow, that could get complicated! For sure. But look at the current situation where vast quantities of paper and vast quantities of person hours are involved in creating and arbitrating and tweaking and debating the meaning of human-language-based regulations...

There has to be a better way and maybe, just maybe, some techniques developed for software engineering can be applied to the area of regulation.

I get frustrated when I hear folks go back and forth on the subject of more or less regulation. The word "better" gets thrown into the mix regularly. For some people more regulation is better regulation. For others, less regulation is better regulation. For me, better regulation is better regulation. We need to find a better way to express regulation first because it is currently not terribly effective. Then we can debate whether there should be more of it or less.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies