Writing Law Like We Write Code

A old typewriter languishing in a field of amber grass.

Writer's Block by thorinside on Flickr

As I, and others, have remarked before: laws bear certain resemblances to computer code. A state’s constitution is like the operating system for that country. We have different types of government: democracy, monarchy, &c, just as we have different operating systems. Even among a particular system, each state has its particular version, with its own customs, forms, and processes, reflecting its unique politics, geography and people. Similarly, everyone’s computer is slightly different, with different settings, themes, and so on. Individual statutes are like software, specially written for that system, and customised to its individual needs.

Like computer code, legal code needs to work, and it must be written carefully to ensure that it does. First comes the idea, whether it’s a law prohibiting flag-folding, or a piece of software for managing your gardening. Then someone writes a first draft. Whether this is a congressional aid composing legalese, or a geek writing C, the process is broadly similar. After the first draft, however the processes diverge sharply.

A computer programmer can test their code by running it. The writer of the gardening-management app can try it out. They can run it on different hardware, and see how it interacts with other software. They can test the user interface: push all the buttons, and see that they have the desired effect. If something isn’t quite right, they can tweak it, trying different options, to see what works. Perhaps the user-interface is functional, but counter-intuitive. The software designer can test a number of alternatives, and see how people respond.

Laws do not have that same luxury. Society is – surprising as it may sound – far more complex than a computer system. Perhaps the flag-folding law will simply cause people to roll their flags up instead. Perhaps it will cause people to get rid of their flags, because they can no longer store them. Perhaps these are desired effects, perhaps not. Either way, the results are unpredictable, and hard to anticipate: it is very difficult to conduct a beta-test for a law.

Perhaps we should use better techniques to write law? Ed Felten thinks that writers of literature may have something to learn from the way that code is written. He’s referring to the tools and processes that coders use: version control systems, and iterated release cycles. I think that legislators can learn even more from coders: unlike authors, they are writing prose which is functionally a form of code. Computer scientists have developed robust principles for writing good code: do it this way, and your code will be easier to write, and easier to maintain. It’ll work better, and when it breaks, it’ll be easier to fix.

Computer scientists are fundamentally lazy people. They want to do as little work as possible, outsourcing as much as possible to tools. We write modular code, define robust data types, and use standard libaries, so that we only have to implement things once. Once you have a piece of software for flobbing widgets, whenever you’re writing some software that needs its widgets flobbed, call on that module, or library. We like clear interfaces, like APIs, and SDKs, so that we can focus on the logic of the code, rather than on working out how to talk to that other piece of software, or wondering what sort of order it wants lists in.

Legislators have a greater need for these approaches that coders do. Coders use them for efficiency, however, it is quite possible to develop code “the hard way”: it just requires constant testing, to make sure that the code does what it’s meant to do. Legislators, of course, do not have this option, but they still write legal code flatly and natively. It’s incredibly hard to check laws for bugs, errors, and vulnerabilities. As with software, especially given society’s complexity, it may take a very long time before bugs make themselves known, so they’ll be extremely difficult to correct. Anything that can be done to make laws easier to write, parse, and debug will reduce the incidence of bugs, greatly improving the law.

Legislators need all the help that they can get to write laws well the first time. Coders have discovered a number of techniques to help. Legislators should be listening.


About flamsmark

I do privacy at Mozilla. Years of security have left me incurably paranoid. Tech, policy, security, privacy, & anonymity are good. Open is better. GPG: 80AF07D3
This entry was posted in Commentary, Essays and tagged , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

What're your thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s