It is difficult to get a man to understand something, when his salary depends on his not understanding it.

Why Computational Law?

Part I. The Problem with Legal

The status quo sucks

(tell us if you've got something to add)

Just on commas alone

Broken law in other guises

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.

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.