Contracts, Computers and Cucumbers

1. Translating Code

How do we translate legal code into programming code? It's not like 500,000 middle-aged lawyers are going to wake up one day and suddenly start programming. But some of us better. If not, we risk laws written by machines created by programmers. I discuss this risk below, concluding with a suggestion for how non-technically minded lawyers might help translate legal code into computer code.

2. Ethereum

"Caught in that sensual music all neglect/Monuments of unageing intellect."

-- W.B. Yeats, Sailing to Byzantium

On the one hand, we should be leery of people who endorse discarding centuries of common-law and the entire legal profession in the name of disruption alone. On the other hand, there are some profound innovations taking place right now that can and will reshape law. It's foolish for lawyers to ignore them. The Ethereum platform is an example, offering the promise of simplified contract creation and automating contract performance. The concept is pretty darn cool. In slightly overheated prose, a recent news report explains thus: "With Ethereum, one could code a constitution for a nongeographic country that people can choose to join, pay taxes to, receive benefits from and cast votes in — and whose rules they would then have to obey. One could design a transnational microlending program or a scheme for universal basic income or a new kind of credit score. In one online video two Ethereum pioneers demonstrate how to code a simple marriage contract. The world’s next social contracts, the successors to the Declaration of the Rights of Man and the U.S. Constitution, could be written in Ethereum’s programming language."[1].

3. Words Matter

Time will tell if Ethereum lives up to its promise(s) (though the contracts won't look simpler to most people just yet). The people behind Ethereum are of course (mostly) not lawyers. You'd expect them to get the law wrong on occasion. Sure, I can build a web-site. But it doesn't mean I can build a secure server for a bank. By the same token, just because a hacker can read a law or a contract doesn't mean that he or she is at all capable of drafting one. So (as an example) when I read sample code for a contract that included "proof of intent" as an element, I heard my contracts professor (that's you Professor Greenfield) raising his voice and asking me if I planned to say anything.[2]

4. "Unbreakable contracts?"

Another post on Ethereum says that in the future we will be able to use the platform build "unbreakable contracts." I immediately thought back ten years to the notion that investment bankers had figured out how to take risk out of investment. We're still cleaning up that mess. I don't think that there is an ounce of malevolence in the brilliant inventors behind Ethereum. This is fabulously creative and innovative technology. I'd personally like to be part of making it better and accessible for non-technically minded lawyers. Its creators can't be faulted for not knowing what they don't know and in getting caught up in the moment. It's the fault of lawyers -- and that's because (in part) there aren't enough lawyers who actually (1) are willing to understand the technology at a granular level and (2) can support innovation while providing the right guidance.

Why is the notion of an unbreakable contract problematic? It assumes that software can create perfect understanding between people, and that all terms in a contract can be described in code (which is language, still). There's a difference between a payment guarantee (like a letter of credit, for example, in old world terms,) which is triggered if and when a specify event happens. Can you automate that using crypto-currency and do it better? Maybe. But selecting which events are important to specify is one thing ("completion", "substantial completion", "delivery" etc) deciding what those things mean is something altogether different. And endlessly complicated. This doesn't mean that contracts can't be better and that Ethereum can't help streamline the process. But the notion that cases, laws and lawyers aren't relevant or are responsible for complexity isn't quite right. The fact that laws are complex is at least in part because people are complex and our transactions are too.

5. Cucumber

How can lawyers help, without becoming programmers?

There are some interesting development tools for non-programmers that may be useful. While working on a project last year I was introduced to the concept of "behavior driven development" using a tool called Cucumber. (For resources on cucumber see footnote 3). Using cucumber (and the wonderfully named "gherkin" language) you write a feature and scenarios that you want software to have in plain language. A programmer can then take this plain language and build tests and functioning code that implement the non-programmers’ feature description. Stay with me -- I'm going to back to law in a second.

Say you want to have a contact form on your web-site. Here is how you might describe the functionality in Gherkin:

Feature: Contact Form Feature

Scenario: Contact Form

1. Given I click 'contact'
2. When I fill out the contact form and click submit
3. Then an email should be sent to 'contact@impassebreaker.com' from ' abcdefg@impassebreaker.com'
4. And that email should contain the contact message

This plain English description is then used to write a test -- the creation of which can be partially automated. And code is then written to pass the test. And then we eventually have a functioning contact form on our web-site.[3] It works. You can use it describe features and software without knowing how to write code. (And once you get started it's only matter of time before you start picking up some of the code too, if that's an interest).

What does this have to do with practicing law, or automating the practice of law? Well . . . what if we wanted to build a tool to help decide choice-of-law questions governed by the Restatement Second of Conflicts? How would we start to take code and turn it into software? Cucumber seems an ideal way to start:

Feature: Choice of Law
Scenario: Written Contract

1. Given there is a contract dispute
2. Given the contract involves a written contract
3. Given the contract contains a choice-of-law clause
4. Then the court should determine if the choice-of-law clause applies to the dispute
5. But if the contract does not contain a choice-of-law clause
6. Then the court should apply Restatement Section 188

True -- turning this into passing tests and working code will take some time, but this is what a programmer friend calls an "iterative" process. Maybe it's too ambitious, maybe not. But for lawyers to have continuing relevance, and a voice, we have to start. Tools like cucumber will make it easier (and fun).

We need a Cucumber and Gherkin for lawyers.

----------------------------

*  These are my opinions only and may not reflect those of past, present or future clients, or of any law firm with which I may be affiliated.  I'm a lawyer but none of this is intended to be legal advice or a legal opinion.  

** For some very interesting insights into law and programming from a practicing lawyer and programmer check out this blog, by American lawyer Casey Kuhlman, who has a firm in Somalia. (Yes, the country). I came across Casey's blog while working on this post. Wonderful insights into automated contracts and Ethereum.

[1] The quote comes from , Aljazeera, April 7, 2014.

[2] Why might it be wrong to make "intent" an element of contract creation? Intent is relevant, sort of, but presumed when a contract is unambiguous. This makes sense if you think about it and can be a tremendous time-saver. If you admit something is your signature, the law presumes you understood what the document contained and intended to be bound by it. It's (generally) up to the person trying to avoid the contract to prove that they did NOT intend to perform. This notion took centuries to develop and in the U.S. we have 50 different sets of state laws that can apply, each with their own nuances. Is this cause for simplification or standardization? Maybe -- but it depends who is doing the simplification and standardization and what their motives are. It's a mistake to think that people without legal education and training can or should understand every intricacy of contract law -- to say nothing of the rule against perpetuities or the hearsay evidence rule. You can complain about lawyers but Shakespeare didn't actually mean that killing lawyers first was a good thing -- these words were put in the mouth of a villain. It's up to lawyers to show our worth and to help translate legal concepts to non-lawyer coders though. We can't simply expect people to get it and to whine if they get it wrong and we've been sitting on our hands. And we can't afford to be asleep at the wheel while new forms of contract are created.

[3] For more on Cucumber, check out out the cuke website -- "http://cukes.info" --and "The Cucumber Book", by Matt Wynne and Aslak Hellesoy (Pragmatic Bookshelf, 2012), available on the pragmatic programming website <a href="http://pragprog.com/book/hwcuc/the-cucumber-book">here</a>. I am working my way through this book and it's great stuff. Hat tip to my friend and collaborator John LaBarge -- a patent lawyer and software architect -- for introducing me to this to begin with.