Law matters.

It matters at a detailed level because we all need to understand rights, duties, obligations and constraints. It matters at a social level because it is the framework for mutually accepted constraint which is part of what defines civilised society.

The purpose and foundations of law are lofty and quite abstract. The immediate practicality of law is often hugely detailed, complicated and largely incomprehensible, even to specialists. That’s not a new problem – as Edward VI put it almost 500 years ago:

I wish that the superfluous and tedious statutes were brought into one sum together, and made more plain and short.

That line is taken from – and this post prompted by – the launch of a Cabinet Office initiative on Good Law which aims to ensure that law is necessary, clear, coherent, effective and accessible. It’s hard to argue with those characteristics. But anyone who has ever needed to understand legislation will know just how far the statute book is from representing them.

This post is a reflection on that event. It puts forward an idea for making law more usable which I am fairly sure is absurd and unworkable, in the hope that at the very least it might give those whose job is to think about this problem a fresh way of framing the question – and if by some miracle there might be more to it than that, so much the better.

Update: there is now a summary of the launch event (including a video which is two hours, including questions and discussion, but well worth watching at least the opening presentations). There is also a lively discussion among the contributors to a live chat at the Guardian public leaders network.

Some law is simple and powerful. Years ago, when I worked on benefit fraud, the Theft Act 1968 was one of the tools of our trade. Its opening words distill its essence:

A person is guilty of theft if he dishonestly appropriates property belonging to another with the intention of permanently depriving the other of it

Some law is far from simple. It is hardly possible to sustain the basic clarity of that definition of theft in creating the 4,000 further criminal offences which were apparently enacted between 1983 and 2009. The loss of simplicity may result from the detail and complexity of what it is trying to address, for example the obligation for a mariner to pay national insurance contributions may depend on whether his ship has sailed beyond the River Elbe. But all too often the complexity comes from the structure of the law itself. A power may be inserted in one act by a provision of a second act to produce regulations which may have effect in part by amending a third act or any number of other sets of regulations. It is possible to navigate along those chains, but it is not easy. The diagram at the top of this post, taken from the good law report, shows the web of effects of just one Act, the Companies, Audit, Investigations and Community Enterprise Act 2004. It is not a pretty sight.

So the fact that there is a problem is clear enough. The question is what can be done about it. I will not attempt – and am not qualified to attempt – anything like a comprehensive answer to that, but I do want to reflect on one aspect of the problem.

Legislation does not spring fully formed from the heads of parliamentary counsel (and secondary legislation does not spring from there at all, but let’s keep things simple). It is the culmination of long and complex processes which express the underlying intention in different ways at different stages. The general direction is usually from the more general to the more specific – green papers go white, primary legislation generates secondary.

Legislation is far from being the only area of life where this is true. The development of any system or process will tend to go through some version of it, it just won’t have legal force at the end. One of the more obvious parallels is with software development. Commonly that’s seen in terms of law as a logical system, typified by this remote contribution to the good law launch:

I am a former computer systems analyst and now a solicitor. I believe that reducing statutes and case law to a series of nested if-then propositions is possible and would make the law far more accessible to anyone who is able to access a computer. Such computer systems used to be called expert systems. With this new initiative has their time now arrived?

There is a lot of power in this view. In principle such an approach should support a much more direct link from at least some kinds of law to implementation. There are powerful tools based based on just that perception, such as Oracle Policy Automation, which are already starting to be used in some parts of government.

But in this context I am less interested in law as code and more in law as coding. To whatever extent law is like software, is drafting law like writing code?

As John Sheridan pointed out at the launch event, the process of software development has become increasingly sophisticated, not just in the availability of tools, but also in softer techniques such as pair programming. Could similar techniques help create clearer and better structured law?

One starting point is to consider where the definitive version of any piece of software is to be found. Ultimately there is some machine level code which is the set of instructions actually followed by a computer. It is though incomprehensible to humans. Sitting above that is source code which is written by and comprehensible to humans – but only highly expert ones (and the more powerful the software the less straightforwardly comprehensible the source code will be). *A step back again, there may be documents which capture the logic of the intended system. Critically in this context, that is the first level for which the primary audience is human. Beyond that, there may be various documents capturing requirements and intentions, but those are descriptions of the intended system, not representations of it. For a system of any complexity, there will also be some kind of architecture which sets out the role of each component and how each relates to all the others.

There is no arguing with machine code: it does whatever it does, and so is undoubtedly definitive in one sense. But in a different way, there is no arguing with higher level requirements: they should be the definitive description of what is intended.

If you want to know how a system works and what it does, you are likely to be much better off starting with architecture and working down towards code than starting with some arbitrary code and trying to infer architecture.

How does any of that map to legislation? Source code is probably the closest match to legislative text. General requirements are, perhaps more loosely, analogous to policy documents. But what of more detailed specifications? And where is there any sense of architecture?

As it happens, there is a place in the legislative process where high level system logic is captured, though one I don’t think was mentioned at the good law event – instructions to counsel. These are curious documents, with no constitutional or legal status but immense practical significance. They are supposed to be the most complete, rigorous and systematic specification of what the legislation is intended to achieve and in theory (though I suspect vanishingly rarely in practice) should be all that is needed to allow parliamentary counsel to draft legislation which correctly implements ministers’ intentions. In order to do that, they need to operate at several different levels at once. They specify the system logic – the if-then statements both for the policy core and for the inevitable edge conditions. In addition, they both communicate the intention, against which more detailed parts of the solution can be tested, and also set that in context, and may illustrate what is intended in one area by analogy with what has previously been done in another.

Nobody would pretend that they are a light read, but they do have real advantages over the legislation which they generate. The first is that they are comprehensive:  the intention is in a single place, even if the legislative implementation is scattered over new and amended statutes. Secondly, they are continuous prose: they tell a story in a way which the more code-like text of legislation will never equal. Thirdly they are more easily testable: it requires less specialist knowledge and expertise for a minister or policy official to ask themselves whether what the instructions describe is the outcome they intended to achieve. And finally, they are rigorous: much of the virtue in producing instructions lies not in the finished product but in the sometimes painful process of being made to translate implicit or unspoken aspects of the policy into explicit requirements.

A good set of instructions, therefore, is a robust description of the intended legislative effect. The actual draft legislation is either a faithful representation of the instructions, in which case it can have no greater information content than the instructions did to start with, or it fails to be a faithful representation, in which case it is wrong (I am, of course, massively over-simplifying here – ignoring both how legislation changes through its parliamentary passage and the fact that there are already established – if exceptional – ways of ascribing meaning to law other than just through its own language). So we can ask again, which is the definitive version. In the world we know there is only one answer: it is always the legislative text. But perhaps there are advantages in creating a world where the answer is not so simple.

What if we were to give primacy not to the legislation but to the instructions? Put like that it sounds absurd, but what if we were to ask instead, what if we were to give primacy not to the technical coding, but to the agreed and understood system requirements.

The effect in one way would be related to purpose clauses and recitals, both of which try to make clear what the legislation is intended to do before getting into all the detail of doing it – though neither of which seemed to find much favour in the discussion. But it would be a much bigger change than that. Perhaps the most powerful feature would be that they could start at the level of architecture, embodying a version of the network diagram at the top of this post. They would map the landscape to set the reader’s bearings before diving down into the greater detail. They would shift the political debate, with the primary question always being whether the intention is clear and has been fully captured, rather than time and energy being spent on technical amendments which nobody understands.

More subtly, they offer some chance of bringing some of the narrative clarity of case-based law to the more arcane structures of statute-focused law. Richard Heaton made a powerful point that much law is taught and learned through stories, the cases which bring the law to life and set its boundaries in a way very different from the endless technical detail of administrative and other areas of law. That immediately makes it easier to engage the interest and contributions of the great majority of people who are constantly affected by laws of which they have little understanding and over which they have little influence.

So my modest proposal is this. Recognise instructions to counsel for what they are: the definitive statement of what the law should be. Let that be debated by parliament – and by all the rest of us. Treat everything we currently see as legislation as technical implementation of that architecture, still vitally important, still needing the highest quality of professional skill in its construction and application, but of no more interest to non-specialists than the source code of a browser is to those reading these words.

This may be a completely ludicrous idea. I am more than half inclined to think it is myself. But let me end with a thought experiment. If we had the freedom to start again completely, without any sense of how law should best be made and without any burden of history or tradition, what might we then invent? And would that be more like the Westminster model we are all so familiar with, or might it be closer to the approach I have sketched out here?

Source code picture by Sebastian Delmont, licensed under creative commons

Comments

  1. Interesting post and one that everyone needs to consider because the law affects them. Yet, I have to wonder if we are in danger of debase the law, and ourselves, by thinking of the law as a computer language. Human life, fully understood, does not follow a computer logic because it frames computer logic. By contrast, human life does not stand outside of nature and its logic. Thus, we are bound, as rational animals, to attempt to discover the law and what it means and how we are to live. Societies in the past (and present) have tried to live by strict laws and yet, they find that they have to constantly revise and adapt to the human condition. Expert systems are never the answer because they can never be better than the expert. For the reasoning behind that statement it is the same reason why we cannot build a “thinking” computer. http://leidlmair.at/doc/WhyHeideggerianAIFailed.pdf

    What we see in this attempt is a modern fallacy and a modern conceit that we can do away with philosophy and political philosophy, of which the law is a subset, for discovering the best way to live. I think it is best to return to Plato’s dialogue Minos and start from there for our journey. http://faculty.cua.edu/lewisb/MinosTransl.pdf

    I thank you for a stimulating post and one that helps us begin the journey to thinking again about the law.

    1. That’s a very interesting challenge, and one which we should all take seriously. Let me offer three quick thoughts in response.

      1. Analogies are always imperfect and so need to be used with great care. I stand by the view that thinking of the law as if it were code can help illuminate some of the challenges; I wouldn’t want to argue – and hadn’t intended to argue – that the law is or should be code.

      2. ‘Law’ is a very general term. The task of determining whether or not someone has committed murder (or whether it is murder that they have committed) is very different from determining whether somebody is entitled to a pension or has broken the speed limit (and speed cameras have already completely dehumanised the latter). Different tools and approaches may be useful in different contexts.

      3. I wrote the post as a way of helping myself think some of this through, and I might have been clearer if I had done more editing before publishing. In particular, I would probably have focused a bit less on code and a bit more on architecture: in a sense, one of the key questions (as I understand it) which the Good Law project is raising is whether there are better ways of structuring law which would make it easier to understand in a very basic way what it is. I think the tools and approaches of systems architecture might be able to help with that – and it is at least worth the attempt.

      And surely the point of expert systems in not so much to be better than the expert, as to be better than the inexpert?

      In all of this I should be clear that I am neither a lawyer nor a systems architect (or any other kind of IT professional), so discount appropriately for lack of domain expertise.

    2. Hi Stefan,

      I think I was overly negative over on the Guardian #goodlaw discussion – by the time I saw your reply, the comments had closed.

      There’s a great deal of meat in your latest post here – I’ll only try and address a couple of points.

      Firstly, I suspect your idea of working with instructions to council rather than actual amendments could be quite powerful inside government, even
      if it were to impinge (directly) relatively little upon those of us outside. It would be interesting to know at what stage in the development process you would expect the instructions to council to become public.

      Secondly, if we are thinking of law as modelling a set of narratives with desired outcomes, I’d suggest that encoding such a model will be good for:

      * checking internal consistency

      * re-testing iterations of the model and seeing whether your narratives (tests) retain those desired outcomes.

      What it’s perhaps not so brilliant at is determining whether your collection of narratives is complete (though the ability to re-test as per above is likely to be pretty useful as you extend your stories). There may be some risk of a problem Nate Silver describes in The Signal and The Noise: some baseball teams began to perform badly because they became so obsessed with the application of statistics that they neglected the parts of their game that were not amenable to such analysis.

  2. @pubstrat #GoodLaw – I believe the answer to your Q of s/w coding analogy & code/architecture is #ModelDrivenDevelopment – no manual coding

    Taking an external context view of the problem, you rightly imply different objectives – and motivations, skills, indeed time – of a range of users.

    Citizens & just need to know if they are lawful (for example when planning something such as a business or property or suchlike endeavour) but also Citizens should be able to see the rationale for law. All without being an “expert”.

    Several bodies related to law enforcement need perhaps nothing more than the above ? Though the detail may need to vary.

    It is only few who need to “create”. However the point is we are not in a greenfield environment and this is where most complexity lies. That would quickly be the case for greenfield anyway – to your last point – where inter-dependencies would very quickly become paramount.

    Undoubtedly the way s/w development – and architecture more holistically – has overcome the problem of more complexity than a human head can handle is through model driven development and other techniques of layered abstraction. This is more than giving “views” of a system.

    Underneath models may indeed be code, and may indeed be nested statements – programming and mark-up languages have emphasised such for some time now, with Java and XML simply being prolific examples of several.
    But none of the users, nor the policy designers and implementation architects (at least the majority) do not need to see that. Their assurance is from testing.

    Mike Broomhead.

  3. Hi Stefan,

    As a tentative experiment in (quasi) code from (quasi) law, and perhaps even as a minor contribution to #goodlaw, I’ve used my copious free time to make a hyperlinked single file HTML version of the
    Advice for Decision Making (nb as a single file, it’s very much not optimized for 3g connections). It’s not perfect, but perhaps it’s rather more straightforward to navigate than the original collection of PDFs.

    I was also wondering if you had some examples of instructions to counsel that you could point to (I appreciate that there may be difficulties, given their place in the scheme of things). I’d like to think about how they might function in the manner you’ve suggested.

    Tim.

Comments are closed.