“we will need to make sure legal requirements are at least similar across the board”

Legal requirements are something engineers don’t like to think too much about: they get in the way of progress and are generally perceived as a pain in the nether regions. There are some disparaging ideas about what lawyers do on a daily basis that seem to be prevalent in the industry. From my point of view, though, they’re not that different from software developers. They just have extra difficulties software developers don’t have: they can only test their “code” by confronting a judge. In software, we have almost instant feed-back running our code using unit tests. Lawyers, from a software development perspective, are worse off than developers were back in the 1970s: software developers back then used to have to write out their code, have it proof-read if possible, then run it through a shared computer, which could take hours to have access to, just to be told there was one hole too many in the punch card. Today, this process seems impossibly arduous.

Just imagine, you want to get something done – send an HTTP request for example. In order to do that, you have to first write a Word document explaining the rationale and the parameters of your request, the level of service you expect to obtain for the request and the expected level of confidentiality you have for the request. Now you have to refer to the standards and specifications you will be using to implement your request: are you using RFC 2616? Are you including the changes from RFCs 2817, 5785, 6266, and/or 6585? If your request fails to meet some precondition, and you don’t include RFC 6585 in your implementation, how will you handle response code 428?

Let’s say you’ve worked that part out by preparing a paragraph that details that, if the response code you receive is greater than or equal to 400 and smaller than 500, you will treat it as a client-side error per RFC 2616 subclause 10.4 and its subclauses. You still haven’t referred to the appropriate standards or specifications for resource addressing (URIs), IP, DNS, etc. You can probably just at “Microsoft Windows 10, incorporated herein by reference” and let Microsoft engineers figure out the TCP/IP stack, but what happens when Windows 11 comes along?

Now, you will probably tell me this is actually exactly how software development works: a call that looks like this

const result = axios.get(uri)

pulls in several dozens of standards and specifications from IEEE, IETF, ECMA, and probably others. Some of them are referenced more explicitly than others, but by using an implementation of an HTTP client (axios, in this case), you’re referring to RFC 2616 and whichever other RFCs axios implements, using some form of EcmaScript, and ultimately using the IEEE 802 set of standards. Some standards bodies, like the IEEE and IEC, will explicitly refer to other standards as “normative references” in each standard while others (such as the IETF RFCs) are typically looser in their ways of referencing, assuming a stack of standards and specifications without explicitly calling them out.

The closest thing to software code in law is a contract. Just like in software code, terms used in those contracts are “terms of art”: they mean specific things in the specific contexts they’re used in. Just like most developers don’t work directly on the normalization of specific technologies, most lawyers don’t work directly on drafting legislation. And just like the final form an IEEE standard takes is quite different from what an individual contributor to that standard would have come up with, the legislative process is quite famous for not being straight-forward and technocratic, regardless of the country in which it takes place – and perhaps rightly so. Individual lawyers, like individual developers, will typically try to apply existing laws and norms (read standards and specifications) to reach a certain objective using contracts (read code).

So, the real difference is the development cycle: legalese is not so different from C++, C#, Node, etc.: it’s a way of writing specific instructions for specific use-cases. If the only way you had to test your code was to “put it out there”, wait for several years to perhaps see it run once because something went wrong, and then have it tested by having a judge (essentially another developer) step through it line by line while two other developers argue what the code actually means, your code might just look a lot more like legalese.

This post has nothing to do with the fact that my wife is a professor at law, obviously.