What software engineers can teach lawyers

One of the common themes in the work I do is how people think about problems, from my PhD days of looking at how people in different disciplines solved the same problem, through work in fintech and defence, and now to legal design and tech. I see strong parallels between software engineering and legal work, with lessons for lawyers to help them write more effective contracts. ?

Let’s start with the basics. Both lawyers and software engineers are producing text, using structured language, that they want to have a particular effect. To someone not working in the same field, the language they use is hard to understand. Sometimes it's hard to understand if you are working in the same field!

Clarity over confusion

One of the first things programmers are taught is the importance of writing clearly. Programming is like the law turned up to 11: each word has a very specific meaning, so must be used in the right way to communicate meaning to the computer. Because of this, software engineers structure their code to help comprehension, for instance indenting it so loops can be more clearly seen, and using tools that colour code certain terms to make them stand out more clearly. Where software engineers themselves assign meaning to words, they use clear language that reflects what the variable or constant does, just like a defined term in a contract.

Collaboration over competition

Contract lawyers can get bit adversarial, for instance writing payment or liability terms that are heavily biased to their own side. By contrast, software engineering emphasises collaboration. This ranges from open-source software such as Linux or LibreOffice, through shared code libraries, to pair programming, where two software engineers work on one machine, with one coding, and the other reviewing the code.

This stems from understanding that code isn’t static: someone has to maintain it, so they need to understand it. It might be the same person who wrote it, or someone who’s never seen the code before, so if you write and document as if someone else is going to maintain it, you’ve made it easier for yourself when you come back to your code after months or years.

Documentation ?

In descending order of preference, software engineers want code that:

• doesn’t need any documentation
• is supported by judicious comments
• is supported by judicious comments and external documentation

Why? Because the more comprehensible something is without having to read more stuff, the better. Good legal documents are the same: they ideally need to be understood without additional documents, but sometimes clarifying points inline or even having a contract manual can help.

Security through obscurity

Software engineers sometimes talk about ‘security through obscurity’: the idea that you can make a system secure by hiding the details of how it works. It’s a much broader concept than code, but in code terms it might mean using obfuscated code: code that’s intentionally made difficult to understand, in order to be harder to change or conceal what it’s doing.

This may be familiar to some lawyers.

Because software engineers find that sort of thing fun, there are programming languages deliberately designed to be hard to understand such as Intercal and Malbolge.

?Summary

Lawyers have long written contracts in a way that’s like the early days of software engineering: what they produce does the job – sort of - but not in a way that’s easy to understand. Good software engineers know that if they code in a way that’s easy to understand, it’s easier to spot errors, maintain, and change.