During a discussion yesterday in my contract-drafting class, I pointed out that —
- Contracts are not computer programs that will be carried out, exactly as written, by mindless, disinterested robots. Quite the opposite: contracts try to encourage human beings. We generally aren’t mindless, and often we’re anything but disinterested;
- Legal obligations are just one type of human motivator in the toolkit. Steven Weatherley gets it right in his groundbreaking Pathclearer article: Legal obligations are a blunt instrument: They can be difficult, expensive, uncertain, and time-consuming to enforce.
Follow me
Signing a business contract:
I agree that contracts are not computer software, and it’s a shame that they are not. In today’s software development environment, there are many sophisticated tools for testing the integrity and validity of software. In contrast, all too often, when contractors finally tested in court, it fails as a result of avoidable ambiguity, sloppy logic, or redundancy.
These are all things that could easily have been caught if lawyers had tools like software developers. Even so, the analogy of contracts (or other legally binding language, like statutes or regulations) is useful. I think it’s especially useful for business lawyers to think of contracts as software, and remember that just as software coders are taken to task when their code crashes, so will the lawyers when a client loses a case, some business, or even just their time trying to deal with poor drafting.
In the world of software, the support function is highly evolved. Licensees can contract for various levels of support, and in general, software development companies, desiring to reduce support costs, employ srict rules of development and “drafting” or “coding” as they call it. Reuse of proven code is a virtue. Extra words are a waste of precious processor cycles or memory space. Too often attorneys waste time redrafting the same clause, using their favorite legalese, and simple declarative sentences, easily understood, would do just as well.
For the client, the benefit of well-crafted contracts, based on standardized language, becomes readily apparent when they called her attorney for advice. If they used the attorney’s contract, rather than a DIY hodgepodge that they downloaded from the Internet, there’s a good chance that the attorney can give them a more confident answer, sooner, and therefore at less cost. And if attorneys, instead of billing by the hour, price their services like software support providers, they would have the incentive to write better “code” and document it properly, so that when the client calls the answer is readily at hand.
Until attorneys start think more like programmers, the business of law, and in particular, contract law, will remain mired in the past, and lawyers will be less valuable to their clients. Both would be better off by with a more structured approach. Of course, attorneys will complain that mindlessly reusing “boilerplate” is unprofessional. Of course it is. But thoughtful use of boilerplate is at the very heart of professionalism. Just as you would not want your doctor to cook up your prescriptions according to his own biochemical theories and notions of safety, why should your lawyer spent any time redrafting perfectly good language. Lawyers should save their creativity for dealing with new business concepts, technologies and market structures. It is wasted on endless debates over what amounts to little more than stylistic preferences.
All strong points, Tom — as add-ons to the point of the main posting.