Throughout law school, I heard my classmates say they chose to become attorneys because they don’t like (or aren’t good at) math or science. I find that interesting because writing a contract (at least, a good one) requires the same thought processes, analysis, and structure as writing software code.
One of the fundamental principles of software design is abstraction. As much as possible, a good developer tries to find commonly used code and abstract it out to prevent repetition. In turn, this abstraction leads to software with fewer errors that is also much easier to maintain. Good attorneys also use this abstraction principle to create robust contracts.
Here are five ways contract drafting is like software development:
1. Common provisions
One of the ways a programmer uses abstraction is to create components or building blocks of code that they can use over and over again in different applications. These components become a software developer’s toolkit over the years. It only makes sense that you wouldn’t want to have to reinvent the wheel (or, cut and paste snippets of code from another program) every time your application needs to perform a common task. At a more basic level, a programming language already has some of these components built in. For example, it is much easier and less error prone to write x = 2 * 5 than to write x = 2 + 2 + 2 + 2 + 2.
The components in an attorney’s toolkit are provisions, or sections that a contract is divided into. Especially for what lawyers call “boilerplate” provisions, these provisions can be used unaltered in almost every contract an attorney writes. The beauty of this is that the language and the structure of the provision has already been thoroughly thought out and perfected. This makes the process of writing a contract more efficient and less prone to error. Once the lawyer has selected the appropriate provisions from her toolkit, she can spend the bulk of her time perfecting those provisions that are specific to the particular agreement at hand.
2. Party Names
You have probably also noticed that parties to a contract are usually referred to in a shortcut way. This is another way attorneys use abstraction. For example, the main parties to an agreement are many times referred to as Company and Customer or Licensor and Licensee, depending on the nature of the agreement. In addition, usually the parties to an agreement are referred to in a more generic way as Party or Parties. If an attorney is consistent with these terms, the verbiage in the components we spoke of above already contains the correct language. Again, this makes contract writing more efficient and less prone to error. Now you can understand why many contracts don’t use your company name throughout the agreement. If an attorney has to search and replace every instance of Company (or some other word) in a contract, it is more likely that the attorney will miss one of the places where the replacement should be made. This is even more likely in a very lengthy or complicated agreement.
Macros (or #DEFINEs or other similar concepts) are also a way developers use abstraction. They are often used in software to prevent repeating the same code in many different places in the program. Again, this is mainly done to avoid the potential errors that might occur if the developer were to re-write this code over and over again in different parts of the same code base. Errors could occur because a programmer failed to put the identical code in all places (for example, if she changed her mind about how something should be implemented but forgot to change it everywhere). Macros and the like also make code much easier to maintain in the future because, if you want to change the way something works, the change can be made in one place and it ripples through to everywhere this modification is needed.
The definitions section in a contract works in much the same way as macros. Definitions are a way of using common words in an agreement that may not necessarily have the intuitive or everyday meaning of that same word in conversation. If an attorney is going to use one of these redefined words in more than one place in a contract, the definition is abstracted out and put into the definitions section. This practice prevents errors in the event that something needs to be added or removed from the definition of the word. Imagine how cumbersome and error-prone it would be to try to make a change like this in many places throughout the contract.
4. Exhibits, SOWs, and other addendums
At an even higher level, the main body of the contract is an abstraction. It contains the provisions that apply to every transaction the agreement is used for. Exhibits, SOWs, and other addendums to the contract contain the details of a particular transaction. This abstraction allows a client to use the same licensing agreement for many different customers with varying needs.
5. Conflicts and incorporation by reference
Some programming languages also use hierarchical constructs such as overrides and inheritance. An override allows a developer to provide a specific implementation for something that has already been defined at a higher level. Inheritance allows an object to have the same implementation as that of the object on which it is based.
Contracts use these same concepts when they contain addendums or when they incorporate other agreements. Overrides are used in the event of a conflict between the main agreement and the addendums or incorporated contracts. Although the term override is not used, there is a provision that states which agreement will govern in the event of a conflict. In other words, one of the agreements overrides the other.
Inheritance is used in contracts when an agreement has a statement that says something like “any capitalized terms not expressly defined in this agreement have the meaning assigned to them” in the other agreement. In other words, if a contract is incorporated by another, the main agreement typically defines terms and provisions that don’t need to be repeated in the incorporated one unless they differ; this is another form of abstraction.
So, weirdly enough, software development and contract drafting have a lot in common. I think many of my non-techie attorney friends would be shocked by that realization. In addition, some people cannot understand how my software engineering experience helps with my law practice. Hopefully, this helps you to better understand that, even when I am drafting or reviewing contracts that have nothing to do with technology, my tech experience is truly a benefit.
If I can assist you with any of your contract needs, please contact me. I am happy to help.