I’d like to take my “contracts as computer programs” idea (see post below) in another direction. Before doing so, hats off to Ron Friedmann of Prism Legal Consulting who, after looking at my earlier post, spoke much more felicitously of “contracts as code” and discussed yet another extension of the idea with the suggestions that contracts might merit coding with XML tags (take a look at https://www.prismlegal.com/wordpress/index.php?m=200401#post-127).
Alright, contracts as code it is, then. With this idea in mind, recall that, before actually writing the code for an application, a programmer might “outline” the program’s steps using a flow chart to picture all of the “if, then this, else that” meanderings of the program’s logic. Well, I’m not a flow-charting maven myself, nor do I presume to know how to code in any more than a very rudimentary way, but I have at times dealt with the hairiest of contract provisions. These are the clauses with so many internal conditions, dependencies, branches and the like that even the tried-and-true method of merely block-indenting the various dependent clauses and exception-like-provisos leave the drafting lawyers, let alone another lawyer or the client, reaching for the Advil bottle after several attempts at parsing the provision at hand.
Suppose that lawyers mustered enough gumption to learn the rudiments not of programming, but of using flow-charting tools – Microsoft Visio perhaps or some of its less expensive and complicated cousins. Maybe the lawyer will find that, by diagramming each of the clause’s very own “if, this, then yes, do that” internal structure, the meaning will become much more readily apparent, glitches in the logic will stand out more clearly and lay people will finally catch on to how the provision does or doesn’t work.
Case in point, a good ten years or so ago, a more junior lawyer in my then firm and I were asked by a non-US client to explain how a complicated contract provision worked. We started preparing our explanation in standard English prose, all the time mindful that we were not only going to have to hurdle the difficulties that the clause itself presented, but we were also going to have to get over the English-as-a-second language obstacle. Together, we hit upon the idea of using a flow-chart (nothing itself too sophisticated, no legend necessary to decipher the meaning of the use of circles vs. the use of parallelograms). We sent off our fax (little email in those days) and, voila, the client got it right away and readily understood a problem with the language’s logic that we pointed out in the briefest of text that accompanied the faxed chart. Who knows, maybe the client would have gotten the point if we had made our presentation in the “standard” way, but she herself enthusiastically endorsed the flow-chart approach (“one picture is worth, . . .” and all that).
I’ve tried to use this flow-chart approach when it comes to my own drafting and, all too frequently, I catch myself all balled up in a logical bind as I draft in English first, flow chart second and gnash my teeth at my gaffe third. And, yes, when disciplined enough, I even diagram first, and draft in English second.
Oh for a set of flow-charting tools developed just for complex commercial contract drafting. Had it been four years ago, I’d end this post with “Business model, anyone?”