Cucumber Legislation

We are approaching the traditional time of the silly season in UK news and politics, the quiet period when in the absence of real news, the frivolous and the dotty get more column inches than they otherwise would.¹ In Poland and indeed much of the rest of Europe, that period is know as the cucumber season.²

With that slightly unlikely introduction (for reasons which will become apparent), let us return to the question of whether law is code and, to the extent that it is useful to talk about it that way, what ways of producing better code might tell us about making better law. Quite clearly, law is not actually code and it is arguable – and indeed argued – that it is wrong and unhelpful to think of it that way. Just recently, Evgeny Morozov has written about ‘algorithmic regulation’ as a threat to the democratic process. But even to the extent that he is right (which in my view is not very great), it’s a different question to the one I am interested in here.

Law, like code, is a complex system of components, where defined inputs should lead to determined outputs. A critical question in both worlds is therefore whether the black box between the two successfully translates the first into the second. Every approach to software development there has ever been – and there have been many – has been an attempt to solve that problem for code. Approaches to the development of law have been less structured and less eclectic, but again, the purpose of drafting legislation is to give effect to intentions.

In each case, it is valuable to test whether the inputs do in fact generate the intended outputs. For law, that can be quite tricky. One reason for that is that it may take a long time (and a complex process) to work out what the inputs are, never mind what the output is. One reason we have judges is to run just such tests: given a set of facts, and given the application of the law to those facts, what outputs does the system generate? In more complex cases, it can take several sets of judges several years to reach a final answer to that question. To add further complexity, the judicially correct assessment of the meaning of law can change over time, even where the law itself does not.³

Computer code, to put it mildly, is not like that. Because it is not like that, the techniques for testing and validating it are very different. They can in principle be more structured and more systematic – indeed they can in principle and occasional practice produce error free code. But even – or perhaps especially – outside such rarified exceptions, ensuring that code matches intent is a difficult and imperfect process, as it is for law.

And so back to cucumbers and to an intriguing post from Richard Pope about using software test techniques to identify whether regulations are being enforced, by analysing data about activity and matching it with regulatory activity.

There are tools for doing this using a syntax called Cucumber, which as Richard explains

is designed to both be readable, and to be written by, a non-technical person, but can be run automatically by a machine.

But if it is possible to use such an approach to test whether regulations are being applied, why not use the same approach to generate the regulations in the first place?

There are fairly well established tools for turning legislation into decision rules (though their adoption for their core purpose does not seem to be terribly widespread).⁴ Turning decision rules into legislation is a rather different question, but conceptually is not so very different from the kind of behaviour-driven development which Cucumber supports (though ‘conceptually’, of course, can be a very long way from ‘practically’).

All of that takes us back to a question first raised by John Sheridan: if law has some similarities to code, are there tools and techniques which can be adopted from the development of software to the development of law?

The short, but not very helpful, answer is almost certainly that there are. Any longer answer needs to take account of some profound differences – the architecture and structure of legacy legislation compared with legacy code, to take just one example. That might mean that tools and processes need to be quite distinct, but it doesn’t stop the concepts and disciplines having common application.

So Cucumber-driven legislation might or might not be the next big thing – but in either case the idea prompts some important questions and points to useful areas for more detailed exploration. And this is, after all, the cucumber season, a time for speculative fancy with little requirement for strong foundations.

Cucumber picture by viZZZual.com, licensed under Creative Commons

Original post