Cutting code and drafting contracts
I was reading an article that Ross Gittins wrote on job satisfaction and the concept of ‘flow’. One of the tasks at work which sometimes (not all the time) puts me in the flow is drafting contracts. You may find this a little peculiar, but I thought a bit about it, and if you’re a programmer, you will know what I mean.
I don’t know if anyone’s made this comparison before, but I find drafting contracts remarkably similar in a lot of aspects to writing good (programming) code. You have to figure out in pseudocode-type form what you want your code/contract to achieve, then you modularise it (in code modularity and reusability can be achieved by breaking things up into functions, objects, defining constants, etc and in contracts it’s master terms, schedules, statements of work, definitions, etc). Then you write in the actual code, or clauses – which have to be very precisely crafted otherwise you produce unintended effects, or the whole thing falls over. You even have termination/consequences of termination clauses which are akin to try-catch statements.
Optimising code and writing good code involve finding the most efficient ways to get things done, and expressing it in the clearest way possible (you can comment code, but often great code is so simple it speaks for itself). Similarly, the goal in drafting is to express what you want to say in the clearest, most concise way possible without leaving anything out (though you wouldn’t believe this if all you read were American-drafted contracts). Clause headings act like comments in code (they explain the clauses but aren’t operative – most contracts exclude headings from having any legal effect).
Objectives change as well. When your client’s requirements move, your code or contract has to move to follow it. When you amend the code or contract, you also have to make sure you don’t break any dependencies. When you get a sloppy coder making edits to the code, things may break or get confusing. A sloppy lawyer will cause the same effect.
In programming you have libraries of code which can be accessed via, for example, API calls. Some contracts work that way as well, like the ISDA Master Agreement which is used to facilitate derivatives transactions. That Agreement has various sets of definitions which can be incorporated by reference (think the “#include” directive in C) into a Confirmation document, depending on the type of transaction being contracted for. The definitions are then simply used (“called”) in the Confirmation without having to rewrite anything.
One substantial difference, however, is that when you successfully compile your program (akin to executing a contract) and run it (akin to performing a contract), the results of watching your program in action are a lot more satisfying (not to mention more immediate) that seeing your contract in action! And of course, you can’t really test run a contract – once’s it’s signed, it’s gone live!
11:31pm (GMT +11.00) 
I suck.