I’m partial to comparing contract language to software code. And I’m not the only one. For example, on Twitter @dgulbran said, “Programming and contract drafting both appeal to me; they both require logical consistency and attention to detail. I may need mental help.” (Welcome to the club, Dave!)
But the analogy goes only so far. In my recent post on IBM’s Watson, I said, “So Deep QA isn’t going to help you write a contract any more than it could help you write software code.” As I wrote that sentence, I had a feeling that I didn’t know what I was talking about. No surprise there—my understanding of software is purely that of a consumer. I have no idea what goes on inside the black box.
So I wasn’t surprised to have @nanoLadi comment on Twitter that that “Unfortunately, software can write computer code … . It just ain’t pretty … yet.” (I’ve since revised the offending sentence.)
So allow me to revisit the analogy. I compare contract language to software code to suggest how limited and stylized contract language is. So far, so good.
But the analogy falls down when you analogize contract drafting to writing software code. Contract drafting is about what you say and how you say it, whereas software code, I believe, relates only to the “how you say it” part. So contract drafting is a broader task and is less amenable to takeover by our new computer overlords.
If by “what you say” you refer to the logical meaning of what you write and by “how you say it” refer to the style you used I don’t see a difference in kind between contract drafting and writing software. In either discipline both aspects are critical. I am not sure what @nanoLadi means when he refers to WYSYWYG(sic) editors and Google App Inventor as examples of software writing code. Google App Inventor is a graphical IDE that let’s you build user interface and program logic using visual components. This is not even close to having software produce other software from a high level human language description of the intended end result.
maclausen: I think I need to spend some quality time with a software engineer before I go public with this analogy again! Ken
As a former software developer turned transactional attorney, I take partial issue with your last sentence. You are generally correct that automatically creating contracts is not something that a computer is likely to do. However, programming and drafting are closer than you suggest. For one, computer programmers do not just program for a computer — they have to program for each other.
With programming, there is (or, well, should be) the understanding that some person will come along later and have to figure out what the heck it is that your code is trying to do, and how it does that. So, you want the program to both be correct, and written in such a way that people can look at it, and see that it is correct. Both “what you say” and “how you say it” are important.
Apart from the language used and the fact that people are infinitely more flexible in interpretation than computers are, the other major difference is that programmers often have the chance to TEST their code, to see if it works as intended, and to fix it if it doesn’t work right. By the time an attorney sees how their agreements work, it’s often too late to fix them.