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.1 In Poland and indeed much of the rest of Europe, that period is known as the cucumber season.2
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.3
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).4 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
- Column inches are not what they once were, of course, but I use the phrase deliberately since the idea of a silly season has itself rather wilted under the pressure of the constant news cycle, and this is not a week where the news feels particularly silly. ↩
- That seems both horticulturally slightly inaccurate and a bit of a stretch of association, but let’s not worry about that. ↩
- The interpretation of the US constitution by its supreme court provides clear examples. ↩
- The market leader has existed in various guises for at least 15 years, and is now known as Oracle Policy Automation. It is probably most suited to very rule-based processes such as tax and benefits, but even there it has never really taken off. ↩
Lovely stuff – what is the track record of the little known oracle policy automation stuff in making mistakes – and is parliament ever told that it is being presented with something from a computer.
also i can’t comment on Richard’s @memespring blog for some reason so i can’t pass on there the good work of the automated court at Northampton which automatically makes judgements on a huge scale for money claims – it’s britain’s biggest court. https://www.justice.gov.uk/courts/northampton-bulk-centre/money-claim-online/frequently-asked-questions
MOJ is about to open another huge judgement processing centre at Salford i think alogn similar lines in another area of law
also of course speed cameras issuing fines, which became so efficient that there was a public outcry and the intensity of fine issuing had to be turned down.
Speed cameras – and the reaction to them – has more to do with David Weinberger’s very useful idea of ‘leeway’. In this case, the argument could be that rigid rules are much simpler (because they don’t have to deal with every bizarre edge case) but can lead to injustice (when those edge cases happen), so being tempered by human rather than machine application delivers the socially optimum outcome. Or of course, that the humans introduce an arbitrary and potentially discriminatory element.
It’s unhelpful that ‘code’ is such a dominant metaphor – it makes for a poor signal to noise ratio. Notwithstanding that, I think the work John Sheridan is facilitating on design patterns offers one plausible way forward. Design patterns came to software development from architecture, so at least their portability as a concept has been established.
I’ve suggested two such patterns: self-destructing trialling instruments that cannot be referenced from enduring law, and structured statutory notices which inherit properties from reusable templates.
The former would replace commencement orders for pathfinder implementations (Have you seen the latest universal credit commencement orders?) The latter would provide a lightweight and easy to interrogate publishing vehicle for detailed information that the public should have reliable access to, but which can’t practically be included in statutory instruments.
I’d also be interested to know more about actual use of OPA in government – I looked at it a very long time ago (it was something else then, Australian?) and thought it a bit clunky, or perhaps simply beyond me.
Law as code is definitely covered by the idea that All models are wrong but some are useful. I find it does provoke interesting thoughts, but it’s a useful reminder that its wrongness is as real as its utility. There is an even more cucumbery approach to all this which would be to ask how, given modern technology but a completely blank statute book, we would set about recording and communicating law. I can’t imagine that we would use the current model, but I don’t think I could describe the best thing to replace it. That would be a purely abstract exercise, of course, since the statute book is anything but blank, and the hard bit is always the journey not the destination, but it might be useful as a way of teasing out good ways to think about the problem – good metaphors for good law – which could be applied to much smaller steps.
OPA has indeed been through many iterations and owners, originally (I think) an Australian company called Softlaw – one its founders pitched its merits to me in about 2000. I have seen demonstrations of much more recent versions, but not much in real use, so I don’t know how well its theoretical merits turn into actual ones.