Part I. The Problem with Legal

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?

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 2006, Henry Smith considered Modularity in Contracts: Boilerplate and Information Flow
• 10 years later, Primavera de Filippi and Samer Hassan published From Code is Law to Law is Code
• BigLawKM has an essay touching on some of these points: Smart Contracts and the Role of Lawyers
• More practically, thelawlab sketches the future study of law in The MIT School of Law? A Perspective on Legal Education in the 21st Century

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.