Think contracts and code live in separate universes? Think again. They’re more similar than you think. In fact, drafting a contract is a lot like writing code. Here’s why:

1. Each and every word, sentence and paragraph is operative and has a purpose. One reason why both contracts and code seem unintelligible to non-experts is that they tend to be very dense. Both condense conceptual ideas into a minimalistic instruction set to dictate behavior based on measurable inputs. Also crucial is the choice of inputs, which determine a contract or program’s flexibility and responsiveness to different situations.

2. It is important to be concise and clear. Syntax matters! Consistency matters! Just as a computer will only do what you tell it to with code, the contract will only work if the people reading it understand it. It can be difficult to comply with vague language or clauses with more than one possible meaning. If your contract counterparties don’t understand what a provision means, or have a choice of interpretations, unintended and undesirable results may follow.

3. Contracts and code need to do what they’re supposed to. Ultimately, it doesn’t matter how awesome and flashy a program is, or how complicated and legal-sounding a contract is, if it doesn’t do what you want it to. This is probably even more true with a contract, because once it is signed, you may be stuck with it. There is usually no way to “reboot” the system, and if things go south, you can’t restore from the last known good configuration: you are headed for litigation. Like a release version, it is essential that you get your contracts right before signing.

Moreover, a contract has to take into account all possible use scenarios. Just as a coder must anticipate what users will do with a piece of software and make sure that there aren’t dead-ends or overflows, a lawyer has to think hard about anything that could possibly happen in the future. There should be a negotiated, fair, and workable result, no matter what comes up. This risk management function is among the most significant value-add functions of a good transactional attorney.

4. When drafting a contract, it is important to bring in the appropriate reference libraries: statutes, boilerplate, and schedules referencing assets and other data. These are the DLLs of a lawyer’s world. They serve as a form of tested code, which is known to operate as needed, or as a database providing the inputs necessary for the contract to operate properly.

Also important is understanding the current regulatory environment—which statutes, agency rules and court decisions impact the contract. These are like libraries that get incorporated into a contract, whether you want them to or not. They are the operating system that all legal agreements live in, and it’s vitally important that your attorney understands them in order to predict how a contract will operate in the wild.

5. The coder/lawyer has to be a pro, or you’re going to have substandard results. A lawyer who doesn’t understand your business is like a coder who didn’t read the spec sheet. Sure, they can write some code or draft a contract, but the final product probably won’t work as intended.

Think long and hard about your organization’s choice of representation, whether in-house or external counsel. Your contracts protect your relationships, intellectual property and assets—they are the structure on which your business operates. A lot of startups will want to skimp on legal counsel, but that would be exactly as foolish as hiring a shoddy lead developer.

Image credit: CC by Gunnar Wrobel

Author’s note: The idea for this post came up in a conversation with Raphael Carty, CEO and founder of Callida Energy.