To introduce myself, I joined Intentional Software as VP, General Counsel in January, 2003 after a career practicing business law in a large law firm.
Since then I have become intrigued by many interesting parallels that I see in problems that affect writing software code and problems that affect writing contracts. Technological innovations are steadily resolving more and more of these problems in the software domain, while the contract domain seems to remain mired in human piecework.
My fundamental approach has always been to maximize predictability of the future for my clients by minimizing uncertainties in each of their legal and business relationships. I believe a similar approach can be helpful in discussing some of the basic problems that affect both code and contracts.
I thought you might enjoy considering a few things about contracts and legalese that you may not have known, and judge how closely they compare to writing code.
Enforceability
I am learning that in order for code to be compiled and run, every literal in the code must be precisely written in accordance with rules of syntax and semantics of the programming language used. The same is true for contract language in order for a court to enforce a term or condition of a contract.
On the surface, just like writing precise code, writing clear contracts and following rules of syntax and semantics would seem to be relatively straight forward tasks. But as I am also learning, writing code is fraught with uncertainty and prone to human error. I know from experience that writing contracts is too.
Of course today there are compilers that enforce precision, and there are tools for testing and debugging code that reduce many other uncertainties in writing solid code. Similar compilers or tools do not exist for testing or debugging contracts, and the problem of reducing uncertainties in writing enforceable contracts remains unresolved by existing technology.
A contract author can reduce uncertainties in contracts at least to some degree by using objective standards to eliminate as many potential contract interpretation disputes as possible. For example a court can speedily enforce an objective standard for determining a breach or for triggering a right to terminate, such as “pay X$ on Y date” or “aggregate collected purchase price of products shipped (excluding returns, rebates, discounts, allowances and other credits, and excluding freight, insurance and other charges) less than X$ deposited by bank wire transfer in seller’s bank account number 12345 at XYZ Bank, Branch No. 38 in Bellevue, Washington, in any 365 day time period”. In cases like these where no material fact is in dispute (i.e. where the objective amount paid or deposited is not in dispute), you can end your uncertainties within 60 to 90 days after suit is filed by asking the court to enter a summary judgment.
In comparison, a court cannot speedily enforce subjective standards that you often see in contracts, such as “sales revenues less than X$ per year”. Uncertainties inherent in that example include whether “sales revenues” means the total (or net? and how is net calculated?) amount (of what?) invoiced, shipped, collected, deposited or something else, and whether “per year” means calendar year 1/1 to 12/31, any 12 calendar months, any 365 day period, or something else. Other typical subjective standards include: “material adverse change” (IBP v. Tyson Foods) and “misfeasance, malfeasance or insubordination”.
Even the meaning of a seemingly objective term like “derivative works” has been disputed in a court battle entitled Progress Software Corp. v. MySQL AB. Other examples of disputes over the meaning of many commonly used terms appear in a current lawsuit between Sprint Nextel and Nextel Partners. These include disputes as to whether “most recent unaffected public market stock price” excludes historical stock prices after merger speculation arose, and as to whether “willing buyer/willing seller” may properly ignore future risks in the wireless telecommunications industry.
Additional uncertainties arise from the fact that courts often interpret the same word differently when used in different contracts and in different factual circumstances. In cases like the MySQL and Nextel lawsuits where a material fact is in dispute (i.e. where the meaning of a subjective term is in dispute), uncertainties often continue for months or years until the trial and appeals process finally sputters to an end.
And worse, as every law student learns: “no contract can make an opera singer sing on key” – just as I expect you know there is no magic formula that will make a programmer write great code.
So even if your contract is written as objectively as possible, there is still no technology or practical way to make absolutely certain that a court will order the other party to perform its obligations in a timely manner to your own satisfaction.
Use Cases
Our resident geniuses tell me that well written code should cause a program to behave correctly in all use cases, and in special cases with minimal errors. A similar general requirement applies to well written contracts because they should minimize loopholes (error cases) too. Years ago a revered mentor and friend gave me an insightful quote by Judge Solomon:
“The legal draftsman must write for unidentified foe as well as known friend. He must write so that not only can a person reading in good faith understand but a person reading in bad faith cannot misunderstand.”
This all seems so simple. But how can anyone possibly identify, much less implement, every single use case in a universe of potential use cases in a software project - or every single loophole in a universe of potential loopholes in a contract?
In software projects, the programmer needs to identify as many of the primary and special cases as possible and cover each of them specifically. The programmer also needs to identify as many categories of other potential unidentified special cases as possible and handle each of those categories in a more general way. Obviously such a subjective human process to avoid error cases is not capable of absolute certainty.
For contracts the writer also needs to identify as many categories of loopholes as possible, and eliminate each of them either specifically or in a general way.
My personal method is to think like a jailhouse lawyer, someone who has 30 years in prison to look for loopholes in whatever documents landed the person in the clink in the first place. But the problem of identifying and eliminating contract loopholes remains a subjective human process. We still have no technology or practical way to make absolutely certain that no one will be able to find a “get out of jail” loophole in our contracts.
Implementing Contracts
Similar to a program, a contract’s value depends primarily upon the extent to which it is useful to the contracting parties. In turn, usefulness depends upon how well the contract implements all of the terms and conditions necessary for timely enforcement of all of the intentions of all contracting parties. And logically, how well those terms and conditions are implemented in the contract surely depends in large part upon how thoroughly and clearly each party’s intentions are communicated to, and understood by, all contracting parties and their attorneys.
Unlike programs implemented in code, however, courts often allow contracts to be evidenced, construed and interpreted (implemented) not just by objective, clear and unambiguous words on the face of the contract itself. Courts also allow just about any other evidence the court deems relevant at the time of trial, with the benefit of 20/20 hindsight.
Depending on the facts of a particular court case, relevant evidence could include writings and oral statements made before, during and after the contract is formed, and actions and statements of the parties during performance of the contract and at the time of alleged breach or termination. Other variables could include things like the relative bargaining power, education or “sophistication” of the parties, “public policy” considerations and evolving societal pressures, all as seen in the eyes of the beholder.
Courts also impose requirements that each contract be negotiated “in good faith”, and be “fair” and “equitable” and not “unconscionable”, judged subjectively from many unpredictable and different points of view (again with 20/20 hindsight). These sorts of subjective “fairness” uncertainties are so pervasive, in fact, that the late Yale law professor Grant Gilmore even wrote a book about them aptly titled “The Death of Contract”, first printed in 1974. Buy it here. As professor Gilmore wrote, pp. 94 & 98 (10th ed. 1981):
“Indeed the decline and fall of the nineteenth century idea that tort liability is, or should be, based on negligence or other fault matches the decline and fall of nineteenth century consideration and contract theory…. The two stories are, of course, halves of the same whole and the same ‘explosion of liability’ has manifested itself, perhaps even more dramatically, on the tort side than on the contract side. … We are steeped in the idea that law is process, flux, change; our relativism admits no absolutes.”
Obviously it is extremely difficult if not impossible to predict or control what variable, subjective “facts and circumstances” and other considerations the court may, or may not, deem relevant “outside the four corners of a contract”.
And a court only brings an end to a dispute based on whatever evidence the court deems relevant. So, unlike programs implemented in code, you can never predict whether or not a court will interpret a contract fairly from your own point of view.
In conclusion, I’ve had some fun articulating a few of the interesting similarities I am discovering between code and contracts, and I hope these thoughts have been interesting for you as well.
Recent Comments