Commercial contracts are a lot like computer programs. No great news to my lawyer/programmer friends who are trying to develop software that assists in the drafting of contracts.
Think about it. The typical bank credit agreement has a host of definitions that are like the variables in a program; little storage boxes that hold the “value” (i.e., the words comprising the defined term) assigned to each variable and that later get used throughout the program; er, I mean the credit agreement. And the various representations, warranties, conditions and covenants are like various “if-then” modules; if one of the contract parties does or doesn’t do thus and so or if a certain event outside even the contracting parties’ control does or doesn’t happen, a party does or doesn’t breach a representation/warranty, satisfy or fail to satisfy a condition, breach or not breach a covenant.
The analogy can be stretched too far, of course. Contracts don’t’ operate computers, contracts shift risk, thereby lowering the costs of dealing with events that happen over time in circumstances where it’s cheaper to deal with the future than to try to cram performance into the present. Unlike computer programs, the language in which commercial contracts are drafted by US lawyers isn’t governed by a strict syntax and semantics which admits of little or no vagueness and ambiguity. English isn’t, thank God, C++. But certain things do follow from even a properly cabined version of the analogy.
What relevance to commercial contract drafting. Well, several points of relevance. First off (and the subject of this post), one of the reigning aspects of computer programming today is something called “object oriented programming” or OOPs (a word not at all foreign to this lawyer). One prominent aspect of OOPs is the creation of standardized computer programs parts, modules if you will, that are written, tested and known to a high degree of confidence to carry out a particular task pretty darn well so that a computer programmer writing a new application can borrow the module from a library of same for use in the program under construction. Saves time by avoiding a reinvention of the wheel and makes for better quality control by piggybacking on the effort at testing that went into the module’s creation. It also allows the program to be analyzed on a piece-by-piece basis so parts of a program that may turn out to be millions upon millions lines of code can be worked on and understood separately by a team of programmers and then linked together. (Not to say that a whole host of other problems wont’ follow from the complexities of the linking-together exercise).
Most law firms have contract or brief banks. Stock clauses that have won the hearts and minds of the lawyers in the firm. These get linked together like the modules mentioned above to form a contract. As we warn all junior lawyers (and ourselves in our better moments): don’t be a slave to the forms, THINK about each word and clause and about how they’re put together.
But wait a minute! Think about each word. No. That’s my point, much of what we lawyers do even when we’re doing it superbly well shouldn’t require thinking about each word. There should be, not just within firms but even between them, more commonality of language in the contracts used so that junior and senior lawyers alike don’t have to read each word because they’re confident that, within certain confines, the words are the same contract to contract within a given category of contracts. How many times have I had to read each word in a 100-page credit agreement; confident that, say, 85% of what’s intended to be said comes from a stock set of ideas, and all I’m really doing is making sure that the language works as intended by all from the outset.
This is silly; efforts should be made to standardize contract modules that lawyers all over the country can count on to say the same thing that everyone in the field of law from which the contract comes knows ought to be said. Pie in the sky? Well, I don’t underestimate the problems of arriving at uniformity. Just look at the difficulties in coming up with uniform state laws. And, no, my litigator friends, you won’t have your business curtailed all that much; again, to take the uniform laws as my example, there’s plenty of argument over how to interpret the standardized language in Article 9 of the UCC.
But let’s face it business lawyers: The value we add doesn’t come from watch-dogging each jot and tittle in a 100-page agreement; it comes from the customization and tweaks that affect, in most deals – even the big-ticket deals, but few of the clauses before us in the contract at hand. It’s the 10%-inspiration, not the 90%-perspiration, that we are (or ought to be) paid for. And junior lawyers ought to learn from the standard clauses that a nationwide (?) committee of the best and brightest lawyers in a given field have labored over. And, again, the standard-clause approach I’m advocating can have its uses not just in the house-closing transaction, but in the mega-deals too.
They’ll be plenty of work, good and challenging work, left to be done in adding the custom language and revisions to the standard clauses once they’ve been adopted. Inter-firm standardizers of contracts unite; we having nothing to lose but billable hours that shouldn’t have been the billed to the client to begin with! (A whole other post, that.)
vagueness in contract...building a home and the builder is telling me I have additional charges on top of my allowance..
ie.....Cabinet allowance 6500.00, I spent 3500 over which I am responsible... but his price of 6500 stated that it included installation. Now he is saying that it does not. Is this vagueness and can I do anything about this?
Posted by: Geoff Kersey | May 24, 2005 at 05:53 PM