The Case for Redesigning Caselaw

To a jurist or a legal draftsperson, caselaw probably looks like a reliable, elegant way to record what legislation really means, in context.

To a programmer, it looks like a collection of bugs, for a program that was badly written in the first place and isn’t being maintained by its authors any more.

The programmer then goes looking for the bug-tracker for the criminal code and there isn’t one. At this point their head explodes.

Introduction

When a statute fails to deal with an unexpected situation, the courts fix it. This is a lot like fixing bugs in programs, except the ruling judge does so by publishing a careful explanation of what went wrong, why, and how they fixed the bug. But …

• What if the bug is fixed for one pattern of evidence but not for another?
• What it it’s only fixed for one section of the law, but not for any another?
• What if it’s fixed on Ontario but not in BC?
• What if there are many fixes? Or very many fixes?

That’s exactly what programmers see in any much-ruled-upon part of the law, and it terrifies us.

Last week, in Redesign, Sam Miller proposed redesigning the justice system. This week, I’d like to propose redesigning its bugs.

Computer programs

As a computer programmer, I work out a specification for the behaviour I want in informal prose, and then sit down to write a nice precise instruction for the computer to follow, in a moderately formal programming language. A lot like the language used in section 365 of the Criminal Code.

When I test the program, it either works as desired or I fix it. If I don’t catch a problem, someone will report it as a “bug” in some agreed-upon place and then I’ll be tasked to write a “patch” to fix it. Of course, if the fix doesn’t solve the entire problem, there will be another bug report and another patch. And sometimes another and another.

My manager hates bugs, and especially hates bugs that get past our testing and escape into the wild, where they interfere with people running our programs. If they don’t get fixed and we have to go back to our customers with patch after patch, she’ll soon be frothing at the mouth.

Each patch, by the way, is also work for our quality control team, who make sure that the bug doesn’t happen in some different part of the program, and for our distribution arm, who make sure that a bug fixed in Ontario is distributed to BC.

Imagine I had to write laws in Computer Code

Now look at my favourite section in the Criminal Code, “witchcraft”. In Gold’s Practitioner’s Criminal Code, it occupies half a page and has one practice note clarifying it, pointing to a case. In that case, a judge found one of the terms was subject to misinterpretation (the bug), and dismissed the appeal (the fix). The only bug report is Mr Gold’s.

Yes, the work is carefully reasoned and verges on elegant. That’s one of the reasons 365 is one of my favourites for explaining what I once did as a “legal fabricator[1][i]”.

What it lacks, however, is a bug-fix in the source code. The witchcraft “program” says,

if (Person p does Act x, where x is any one of (a, b or c)
and x is done fraudulently())
then p is guilty of Offence o;

In this case “fraudulently” is an important, independent test. It’s a “sub-routine” that checks that the action meets a certain criteria. and which now needs a bug-fix.

When applied to any of section (a), (b) or (c) of the law, we need to apply the change from the case: the routine now needs to say it covers all “gestures, actions, attitude and the entire comportment” of person p.

Until this clarification becomes part of the statute , it’s an outstanding bug and every judge who needs to execute the “fraudulently” program and every lawyer who has to interpret it has to

• find this case (an “execution”), which is filed under witchcraft, not necessarily fraudulence
• read it,
• find the bug,
• read the fix
• decide if it applies, and if so
• add it to their execution of the “fraudulently” program.

Even my elegant example is really somewhat flawed, when you look behind the scenes.

Weapons Prohibitions Orders, also under W, is Horrible

Compare witchcraft to weapons prohibition orders. Not my favourite section. Twenty-five different heads, references to several different sections, many pages and many cases interpreting it. Including at least one constitutional challenge.

Every one of the cases is an an unapplied bug-fix. Every one of which has to be symbolically “executed” in the brain of a judge, lawyer or, in theory, every person who has to consider it.

Even with Mr Gold’s and the legislators’ careful analysis and organization, it’s an extremely convoluted piece of code. Many many considerations need to be kept in mind, or the practitioner will not come to the correct answer. “A maze of twisty passages, all alike”, to use the words of an early programmer. “Epic fail” in modern slang.

When weapons prohibitions require a police sergeant to ask the crown to do legal research just to tell if she should ask for a weapons prohibition and what it prohibits, then we have a problem. It’s like being given an ”offer you can’t refuse” by the Mafia, but in this case, it’s more of “an offer you can’t understand”.

Like it or not, understand it or not, you have to take the offer. You just hope it works.

What does this mean?

As my friend Peter Miller once said, “our brothers in the legislature are making work for us again”.

Settled problems need sorting. There is no need for them to lie about in a half-fixed state, never applied to improve the code from which they came. We really do need to fold the principles into legislation and definitions, and the implementations into regulations, with some regularity and with some consideration of what’s had to be considered and re-considered by the courts.

If legislators don’t, they’re dumping on their brothers in the trenches, making justice more and more expensive to obtain, and thus denying it to police sergeants and persons without extraordinary means.

Proposal

Yes, I’m proposing the governments redesign their job to include more work. In my view, they should move well-settled matters into statute and regulations, reducing the complexity. The advantage is that it takes the law out of the memory-work and judgment exercise into an area where legal draftsmanship begins to resemble computer science, and the law can steal good techniques from a sister science.

Much of the work in computer science in my life time has been in managing and minimizing the complexity of sets of rules, and there are at least two recent developments that can help.

One of the most powerful advances has been work done on reorganization. We call it refactoring, and big parts of which are now “correctness preserving”. We can test and see if the proposed change to the definition of fraudulent are general or special cases, and make the general cases part of the general law.

There are also experimental programs that can interpret the law, and predict what a court will decide. Those can be used to test out each proposed refactoring of the law, and tell the legislator or the legal draftsperson when a change will cause a different result than they intended.

Conclusions

This is a part of our justice system that cries out for redesign. A police sergeant or a private individual, should be able to read the law and know roughly what they should do. And they should be easily able to know when they don’t understand. At that point, they should be able to ask a reasonable question of their lawyer and get an answer at least as good as IBM’s “ROSS” program provides.

If a person or a desk sergeant can’t do that, then the law’s unfixed bugs deny justice to everyone who doesn’t have a family lawyer. In programming terms, the bugs are a “denial of service attack” on everyone would like to be law-abiding, but have been given an offer they can’t understand.

________________________

[1] All too many people thought the job was making things up, instead of typesetting.