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.
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 below, 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 you would be by starting with some arbitrary code and trying to infer architecture
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 you would be by 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?
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
Leave a Reply
You must be logged in to post a comment.