BASEMENT.ORG

With apologies for the title...

I was mired in reviewing, commenting on and drafting portions of a contract this past weekend. While I bask in the world of technology and design (I couldn't imagine being anywhere else), work often demands that I dust off my law degree and play lawyer for a little while.

As I was reviewing an old contract and folding in agreed-upon terms, it dawned on me how similar contract drafting is similar to writing software (bear with me on this). I've often been forced to justify my law education in light of my sharp left turn after law school. But oddly, the parallels are there.

You don't learn the law in law school. Most exams are open book. It's not really about memorizing and regurgitating information. Instead, it's about thinking a certain way. It's about gaining an ability to understand, deduce and optimize rational arguments. It's also about foreseeing weaknesses in your adversary's arguments.

Just before I dove into the contract, I was coding and I couldn't help but notice a few parallels:

• Define Your Words And Reuse Them. In contracts, you'll often see something like "Seller, as referenced in this agreement is defined as..." and from that point on, a capital 'S' Seller is referenced with clarity. In code, rather than "restating" portions again and again, we create functions that allow for reuse throughout. Much of contract writing is made less painful with this sort of "re-factoring."
• Use Your Words Efficiently. In the law, the less you say the less room there is for ambiguity or (re)interpretation. Think through your words and sentences so that they're airtight. You don't want to leave loopholes. In programming, the more efficient and tight your code, the less likelihood of bugs and errors.
• Write The Outline First. Depending on how complex your contract/program is, if you're starting from scratch, you'd be a fool to start writing out of the gate. Instead, step back and lay out the landscape. Draft an outline n-levels deep that accounts for all the pieces of your code.
• "Exception" Handling. Any lawyer will tell you that a primary role of a contract is that of a reference document for when things go bad. If all is well in a business relationship, the contract is seldom ever referred to. But when things go sour, every word or phrase may be picked apart. As such, it's wise to think through how scenarios would play out against your contract. When coding, a similar premise applies. How much load will this object have to withstand? What if a particular transaction (which is dependent on an outside service) fails? What if the database goes down? Good code insulates itself from or gracefully addresses these "bad scenarios."

A good legal agreement, like a good codebase, is a product of forethought, planning, and an economic use of words. Hmmm....maybe I can tell people I'm a lawyer after all...