There’s a special class of scribe that takes requirements from a client and translates them into highly precise, sometimes arcane documents. Few laypeople can understand these documents and the policies they encode, but they nevertheless have a great effect on everyday life.
The domain of the clients and requirements are often different than as the domain of the scribe; the scribe has to learn to efficiently translate the rules of the business she represents into the precise language of the documents.
When these documents are parsed and analyzed, they’re done by another body. The meaning drawn from the documents won’t necessarily be the same as what the scribe or her clients intended, but the effects of the documents stand, nevertheless.
These scribes are paid a lot of money for their skills, and a lot of people find it frustrating that no one else can do what they do. But ultimately, it’s not really possible have a modern, functioning society without them.
I’m talking about lawyers writing contracts, of course.
The parallels between lawyers and programmers are myriad. These parallels are sometimes trivial, like defining variables; every programmer has seen an employment contract that has text like “Widgets LLC, hereinafter referred to as ‘the Company’”. Defining a variable in this way shortens the contract, prevents redefinition errors, and makes the contract easier to change.
Lawyers also have to flesh out simple ideas (for example, the statement “things that I make”) into really complex and precise statements (“all Inventions that I may solely or jointly author, discover, develop, conceive, or reduce to practice during the period of the Relationship”).
Contracts are more similar to interpreted code rather than compiled code. The contract can be “statically analyzed” (i.e., read by other lawyers) while it’s being written, but its meaning won’t be fully determined until it’s challenged and taken before a judge.
Judges are much more lenient than code interpreters, so typos and other simple errors aren’t commonly held against a lawyer the way they might be with a programmer. Ambiguity, however, provides ammo that opposing counsel can use to change the intent of the contract. That’s a runtime error if I’ve ever heard of one! If only we could give lawyers automated tests.
Much fuss is made about the future of programming, whether it will be text, or some kind of semantic editor, or perhaps something graphical. On the other hand, the future of contracts appears to be a lot more form contracts and contract generation, rather than a dramatic rethinking of their representation. Generated, parameterized contracts parallel either functions or libraries in the programming, although it strains the metaphor a little bit.
It’s also easy to imagine the profession of programming going in the same direction as lawyering. Extreme demand and limited supply has caused engineer salaries to skyrocket to the around (and above, in some cases) a lawyer’s starting salary. The long hours and benefits (free food if you stay past a certain time!) are also slowly starting resemble big law firms. Programming culture could definitely use the specialized trade schools and a the strict pipeline that law benefits from. Our lawyerly brothers and sisters have already been through what we’re going through, and we’ve got a lot to learn from them.
