§Legalese

Why Computational Law, Part I: The Problem with Legal

Legalese Team
Legalese Team
Cover Image for Why Computational Law, Part I: The Problem with Legal

"It is difficult to get a man to understand something, when his salary depends on his not understanding it." — Upton Sinclair, I, Candidate for Governor: And How I Got Licked (1935)

The status quo sucks

Just on commas alone

Broken law in other guises

  • British MPs can't resign (therefore given unpaid job with no actual responsibilities instead)
  • Will voided due to numerically challenged chief justice
  • Clerical error, so inmate freed 90 years early
  • County judge's (incorrect) insistence on procedure led to reversal of conviction
  • JP Morgan to live with lawyers' $1.5B paperwork error
  • Ownership of LA Dodgers rests on conflicting 'final' drafts in divorce papers
  • Motion denied for being "incomprehensible" with footnote quoting Billy Madison: "Mr Madison, what you've just said is one of the most insanely idiotic things I've ever heard. At no point in your rambling, incoherent response was there anything that could even be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul"
  • 1966 federal government publication, Gobbledygook Has Gotta Go: "the flossy, pompous, abstract, complex, jargonistic gobbledygook that passes for communications in government 'has gotta go!' It's too out-of-date to renovate; it's too expensive to tolerate"
  • Punished for dishonest verbosity, attorneys tried to make 70-page brief fit into a 50-page limit by reducing font sizing and line spacing (fined $1000 with explicit instructions that they could not pass the fine along to their client)
  • Motion "riddled with unprofessional grammatical and typographical errors that nearly render the entire [motion] incomprehensible", Florida judge ordered lawyer to re-read civil procedure text in entirety and for attorney to "personally hand deliver a copy" of the court's order along with a marked-up copy of the motion to the client

The law firm business model is...

Everybody now!

Even lawyers feel the pain

Howard Darmstadter's Precision's Counterfeit reads like both a clarion call ("there's got to be a better way!") and a grope in the dark ("one possible idea: don't repeat yourself") by someone who, being a lawyer not a programmer, has no exposure to the disciplines and possibilities of software engineering and language design. Indeed, he talks about debugging contracts as programs; he talks about testing; he talks about using mathematical notation, even flowcharts, to improve clarity. But as a lawyer he doesn't know where to go next with these ideas. Lawyers don't get CLE / professional credits for reading Steve McConnell.

Lawyers haven't heard of language-oriented programming or UML/BPML, whose history has much to teach. Yet contracts are, effectively, business process specifications, where they skip over the high-level modelling and go straight to writing a low-level runtime by hand … using a collaboration methodology that could only be described as pair programming by correspondence, the way chess used to be played during the Cold War.

In that paper, Darmstadter:

  • describes the problem without knowing its name when he suggests that contracts should try to specify why before implementing how; then
  • alludes to literate programming, again without knowing its name, when he suggests that maybe contracts should include comments, or remarks, to help clarify the intent of a piece of code.

The paper is a fun (and cringe-inducing) read. But the current state of the art is all quite ghastly, isn't it?

He knew all the answers. Everybody did. Everybody knew everything and everybody knew all the answers. It was just that the enemy seemed to know better ones. — Iain M. Banks, Surface Detail (2010)

So, programmers to the rescue?

After all, we already invented DRY; perhaps we have a moral obligation to help them avoid reinventing our wheels. And, programmers know very well the XY problem.

Some legal thinkers have even explored correspondences between law and software:

In fact, there's a fairly rich tradition of legal informatics.

But... contracts have more in common with processor design than a web page

The legal informatics tradition is older than most web developers today. Most web developers are used to playing with tech that's only been around a few months, maybe a year. For these, quick hacks are good enough – after all, what's the worst that could happen? Reload the page, if it didn't work, it'll be obvious.

Contracts are different: once executed, they don't change. They aren't like web pages where the odd JS bug is acceptable. Parties can turn hostile – as TheDAO discovered. The stakes, permanency, and failure costs of contracts suggests that it has more in common with processor design than a web page. So move fast and break things does not apply.

"Everything 'THEDAO' tried to be, it could have been correctly and in full compliance with the law. For this reason, what blockchain companies should be trying to do is take complex financial, business, and governance processes and turn them into machine-readable protocols that also tick all of the human requirements, legal or otherwise. A bit of code that does all those things is what a smart contract actually is." — Preston Byrne, Failing Fast vs Failing Unnecessarily (2016)

This is Part I of our series on Why Computational Law. Continue to Part II: 70 Years of Legal Informatics and Part III: Computational Law.