19th September 2021
Some of the best legal drafters you will meet – those who put together formal legal documents such as contracts and acts of parliament – will have a background in computer programming.
This post sets out an explanation for this, from the perspective of an experienced legal drafter, as to why it seems (from the outside) the legal drafting process is similar to the computer programming process.
Of course, this perspective is that of a lawyer and writer – but I hope it is in general enough terms that the comparison it seeks to make is of some wider interest and validity to experienced programmers and others.
(My own coding skills are almost literally BASIC (and some HTML).)
The perspective set out below will be separated out into items, line-by-line, as-a-whole, and stress-testing, as well as a conclusion and a tribute.
*
Items
By items I mean particular symbols or words – the smallest useful things to be typed.
For both the coder and the drafter each item will (or should) have a purpose.
(Even if that purpose is to be deliberately redundant – we once caught out a copyright infringer because they had duplicated intentionally dud code that could not have been there without naughty copying.)
For the lawyer, each word in a formal legal document has (or should have) a purpose: it has been chosen instead of other words, and also instead of no words at all.
Here there is the ‘rule against surplusage’.
If a legal document says a thing then (it is presumed) that thing is there for a precise purpose.
And if it serves no purpose, then it should not be there.
*
Line-by-line
Here we look at lines of code or clauses (or sections or articles) of a legal document – short sequences of items.
The intention with a line or a clause is that there is a thing meaningful enough to have meaning in and of itself – in effect: a proposition.
That one can look at it and say: that line or clause does this – but not that.
Most coders and lawyers are capable of producing such discrete things.
Certainly any competent lawyer should be able to draft a simple clause: ‘[x] shall do [y] in return for [z]’.
But – at least for lawyers – the difficult thing about drafting is not in composing a single clause but with the next two stages.
*
As-a-whole
The first real difficulty with a legal document – as perhaps with a program – is getting clauses to work together as a whole.
That clause one does not contradict clause two, and that clause three is workable in view of clauses, one, two and four, and so on.
In this way, a legal document is usually complex – and not linear.
Each clause not only has to fit in with the clauses immediately before and after (like, say, a verbal jigsaw) but with every other clause in the document.
If clause sixty does not work with clause five then there is a potential problem.
And so, although some legal instruments are readable – sometimes elegant – they are not linear texts like an elementary short story.
I understand this is also the approach to coding – line 60 of a program has to match line 5.
The goal is therefore to create a thing as-a-whole that is internally coherent.
But.
*
Stress-testing
And this is the second big challenge.
One can have a legal instrument – or a computer program – that is beautiful in its internal coherence, where each intricate point works with other intricate point.
And it still will be useless if it does not work in practice.
For legal instruments and computer programs are (or should be) practical things.
Instruments, not ornaments.
If a contract or an act of parliament fails any test provided by reality – then it is not reality that is ultimately at fault.
And similarly (it seems to me) a program that fails a test provided by reality – then it is also not reality that is ultimately at fault.
I have long thought, for example, that draft legislation should always be published – almost in Beta mode – for stress-testing before any actual implementation.
And that all legislation should be subject to regular testing and review, rather than just being dumped on to the statute books.
*
Conclusion
Of course: as you read the above – just as I typed the above – exceptions and differences will come to mind.
And such exceptions and differences are to be expected – for I am not contending that two things are identical, only that they may be similar, and so I am identifying only points of similarity.
I could have posted a sequence of points of difference, though I do not think that would have been an especially interesting post to read or write.
And, again, I aver that although I am an experienced legal drafter, my coding skills are otherwise limited.
But there is, I think, something in the understanding that legal codes and computer codes may have similarities, and also that there is something in the understanding whether the coding processes that go into both are similar.
If there are similarities, then – in turn – there may perhaps be many things that the two disciplines can learn from each other.
*
Tribute
This post is prompted by the news of the death of Sir Clive Sinclair.
In the 1980s my introduction to programming was the rubber-key BASIC shortcuts of the Sinclair Spectrum 48.
It was by learning how to code that I first developed the skills that, later, made me actually enjoy the drafting of complex legal documents.
‘IF [x] GOTO [y]’ has – at least for me – a lot to answer for.
</tribute>
END
**
Hello there – if you value this daily, free-to-read and independent commentary for you and others please do support through the Paypal box above, or become a Patreon subscriber.
***
You can subscribe for each post to be sent by email at the subscription box above (on an internet browser) or on a pulldown list (on mobile).
****
Comments Policy
This blog enjoys a high standard of comments, many of which are better and more interesting than the posts.
Comments are welcome, but they are pre-moderated.
Comments will not be published if irksome.
Seen from the programming side, one valuable aspect of programming that could transfer across is the importance of the interface – what are the expected inputs, boundary conditions? are they defined anywhere? what are the possible results/outputs? are they defined anywhere?
Related to your point, Washington DC maintains their laws on Github, the website that software devs use to maintain their own software. Here’s a very interesting article on it.
https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/
David, my drafting of texts extends no further than drafting of amendments to be submitted to the European Parliament committee that I was seconded to (from the UK civil service).
But, that is an experience that has stayed with me. That necessity for logic, the choice of words (even more so when they are about to be translated into a multitude of other langauges), even before any political considerations.
There is a nice quote in French, from Nicolas Boileau-Despréaux: “Ce que l’on conçoit bien s’énonce clairement,
Et les mots pour le dire arrivent aisément”. I’d translate this as: “What we think through well, we articulate well. And the words to say this come easily.”
The interesting thing about that quote (which I’ve just looked up to check) is that Boileau-Despréaux was the son of a clerk in the Paris Parliament under the Ancien Régime.
Quite correct, Chris. I entirely agree.
In Italian we say: “Chi pensa bene, parla e scrive bene” (He who thinks well, speaks and writes well).
A similarity I, as a lawyer with some drafting experience have identified in discussion with my brother in law (computer science expert) is that coding and drafting are both 90% analysis and only 10% drafting if they are to work well.
I read Jurisprudence but fell (by accident) into IT while looking for a temp job and finding the interviewer (the legendary Jo Seeber) had worked on the first US project to abstract case reports. So, for a brief period in the 70s I was a programmer.
1. Then all programmers came from a rich background. My department head was an astronomer, my programming manager a chemist, my manager a historian and my desk mate a classicist.
2. The biggest influences were Edward de Bono, Grace Hopper and the use of structured English expressed as pseudo code to plan a program in “HIPO” (hierarchical input process output).
3. So – lateral thinking to debug programs (and subsequently drafting outsourcing contract schedules), thanking Grace for being on the money in 1973 when she said the future would be in a little box of power on our desks (everyone else at Univac thought she was mad) and using structured English to break large requirements into simple “if then else” propositions.
4. This is of course is what engineers do, plumbers, electricians and mechanics. What it isn’t is multitasking so don’t be surprised if I mess up the coffee if you interrupt me while I am grinding the beans.
As a computer programmer, I’d reverse that saying to “What one can explain clearly will normally be logically correct”. If you cannot explain it easily, maybe you should redesign it so you can.”
This is why pair programming produces better code. When I have a problem with my code, just the act of explaining my problem to someone invariably leads to me spotting the problem myself. The other party need not even be a programmer, or even a person – we all keep a rubber duck on our monitors, and often explain our problems to it.
Two thoughts to add to the above, which I found really interesting. The first is relating to the concept of ‘dud code’. This seems similar to the Ordnance Survey approach of including ‘trap features’ on maps, which do not exist in reality, so that versions based on their maps can be identified.
The second is something I raised on Twitter, and links to the idea of legal prose sometimes being elegant and readable. Like computer code, this means that sometimes the text looks like something that could be understood by a layperson. There are words borrowed from everyday language, for example. But this similarity is deceptive, because those technical uses may not be understood by those reading it without context. In my day job, I work with science teachers and we discuss the challenge of teaching ‘science English’ to students who already speak ‘everyday English’. The similarities are actually a bigger problem than the obvious technical terms, because students assume their understanding covers the science use too. In fact, science terms are often fossilised language from a previous understanding of the universe, which were borrowed from English but now have a very specific meaning. I imagine there are similar words in law which look, sounds and are spelt the same as in English – but now mean something entirely different when used in a legal sense.
The law should be idiot proof, if only because it needs to be understood by the law makers.
Your post reminded me of this piece by Douglas Adams:
“If you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your own mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that’s really the essence of programming. By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve certainly learned something about it yourself.”
Computer programmes like Precedent books always need to be handled with care.
Computers never make mistakes.
If the end product is not quite right it is human fault and not the fault of the computer.
Any barrister who argues that something was the fault of the computer in any document is skating on very thin ice.
Aristotle did that first.
Although the less said about the use of the GOTO statement the better. Anybody with the habit of using that too often would probably end up writing documents that look like the written equivalent of one of MC Escher’s drawings.
10 IF [‘Unhappy with post’] GOTO 20
20 PRINT [‘Unhappy with post’]
Failed formal review, test on line 10 has no impact on program flow … Always ‘Unhappy with post’
Informally – can determine your meaning 🙂
Or in COBOL
If sw-red-herring = ‘YES’
Move ‘NO’ to sw-red-herring
Else
Move ‘YES’ to sw-red-herring.
I found this in while debugging a program at 3am that had stopped a steel mill in 1982. It was written by a disgruntled monolithic programmer improving his structured programming productivity and was a sub-routine performed over 200 times in the code.
There used to be a GOTO statement in the Employment Tribunal Rules and Procedures,
It refers to the sift, where a judge can kick out an appeal if he deems that it has no reasonable prospect of success.
If he does, then you were allowed to submit another appeal with amended grounds, which would go to the sift…
3.7: If =(no reasonable prospect) then =Rejected
...
3.10: If = (reasonably persistent), then GOTO 3.7
The EAT, generally ignored the rules, treating them as saying what they wanted them to say.
I very nearly challenged them on it, but my barrister of the day was a bit wet and wasn’t up for it.
The rules were amended sometime after that: I think that was a regressive step and maybe it was my fault.
Sorry about that…
They say that law is *supposed* to be open to interpretation, as that gives judges flexibility in being proportional & reasonable when sentencing. There is a large body of law, however, where that is not true. tax law for example. Recent developments in my area of expertise (programming languages) has shown how programming can help with the legal process when said process *is* known to be deterministic and it open to interpretation.
For example: https://icfp21.sigplan.org/details/icfp-2021-papers/16/Catala-A-Programming-Language-for-the-Law
There is scope, and examples now, where both law and code can work together. As Lessig said “code is law” and researchers have now shown that code can indeed be law.
I have been a professional software engineer for over 30 years. As I became more senior in my profession I have had increasing contact with legal documents, and this absolutely resonates.
Software engineers have a horror of what we call “spaghetti coding”, which has its analogue in some of the poorly drafted legal documents I have reviewed. Conversely, I have (albeit rarely) read legal documents of real beauty and clarity.
One observation I do have is that software professionals have access to far better tooling to ensure consistency and correctness than is readily available for legal drafting.
We have type systems and unit tests to ensure consistency and correctness, and change control tools like git to track changes with precision. Some of these could be used in legal drafting, but I certainly have huge respect for those lawyers who draft complex texts well, given the poor tooling available. I have often wondered whether some of the tools and techniques developed in Engineering might be made useful to the legal profession.
My other observation is that many UK statutes, particularly those which are relatively recent, or have been amended by subsequent legislation, are surprisingly poorly drafted.
Fancy bumping into you here Jeremy :)
Unit testing for laws was the first thing I thought of, to ensure that a law is still fit for purpose after an amendment or when the world around the law changes. No idea how you’d do it.
If you learned on the Spectrum and have not progressed much beyond that, then perhaps you have not discovered “Object oriented programming”.
I am not a programmer, so I won’t try to explain it, but I was moved to think about it in relation to the non-linear complexities that you speak of: I think the idea of OOP is to try to address that problem.
Perhaps a similar approach might be taken to legislation?
There is one big difference between computer code and a legal draft. In the former, the steps are ordered and make sense if they are executed only in the order in which they appear. In the latter, there is no such requirement and I think each clause (term, condition, provision etc.) needs to stand up on its own or else expressly state the other clauses on which it depends.
Not always.
Prolog is an example of a programming language where the order of execution is not defined by the programmer, and most languages supporting functional programming paradigms can also be used this way. Haskell, in particular, encourages “lazy” evaluation of terms only when/if they are needed.
A very interesting parallel you have drawn drawn, and very apt. Programing (now called coding) languages accept nothing but the correct use of the language. Any slip up and the program (now App) will bomb out. Consequently, it needs to be tested, and tested again and again using all possible foreseen inputs to see that it deliver the the correct output, before letting it lose on a wider public.
Does it ever reach perfection? Windows 11 suggests not. There is always tweaking that may be done to improve it. I guess the same may be said for law. It may always be improved.
Very sad to hear of the departure of Sir Clive Sinclair. The ZX Spectrum carries a very special part in my heart along with the associated books with games to be laboriously typed out (with contorted finger), but in the process succeeded in learning ZX BASIC. The Spectrum along with the Commodore, Amstrad (Alan Sugar) helped bring a generation around the world into the daily use of computing long before the IBM PC clones took over.
I’m reminded by this post that the great Indian librarian (and mathematician) S. R. Ranganathan https://en.wikipedia.org/wiki/S._R._Ranganathan wrote something to the effect that it would save us all much time and effort if laws were formulated by mathematicians.
Heard this one ad nauseam from analysts when I was working as a corporate tax adviser. If you think you can define in maths what taxable income is and how it is different from any other cash flow (sales, investment sale proceeds, proceeds of part lease surrenders), then do go ahead. Remember, the answer has to be politically acceptable as well.
Sorry Anthony, now realised my reply is very rude. Wasn’t meant to be – driven by old frustration – hope you can understand that snd forgive me.
But there is a basic difference between what natural language does – qualitative, and what maths does – quantitative, which seems to get overlooked in the enthusiasm for all things “tech”.
No offence taken, Owen. I confess that slipped by me. I think SRR was just opining that we have better uses for human intellectual effort than interpreting ambiguously drafted legislation. It seemed also a nice opportunity to raise the profile of a founder of modern classification theory.
For my sins, I was part of an “AI in Law” group as an undergrad (I was one of the few on my LLB with any computer experience).
And I was surprised, when discovering cryptocurrency, how similar the language used (especially ETHereum) was to what we were developing in ’89.
I liked your tag. But, programmer that I am, I reflexively thought “did I miss the matching ?”. I guess you intended the title “Tribute” to be the start of the tribute section, but it’s also plausible that you intended the whole post as a tribute.
My point is that that you’re right, in both disciplines precision and logical coherence matters. A Taliban edict that boys can now go back to school effectively excludes girls, and that is hugely significant. Or is it? It could just be a normal cock-up or simply work in progress. We don’t know.
I agree that beta testing laws is a good idea. That would have seemed crazy to me as a child but I now realise that laws are typically full of errors and misunderstandings and frequently end up repealed or obsolete. So frequently that older people have genuine difficulty remembering what today’s restrictions are! The system is chaotic. Not sure how best to solve it though.
‘But, programmer that I am, I reflexively thought “did I miss the matching ?”. I guess you intended the title “Tribute” to be the start of the tribute section, but it’s also plausible that you intended the whole post as a tribute.’
I intended the tag as…
…a joke.
Sometimes the shortcomings in the law look deliberate. See, eg, the legislation to enable Commonhold. It may not have been nobbled to enable the iniquities of leasehold tenure to persist but the failure to revisit the legislation, plainly not working as supposedly intended, results in exactly that.
See leaseholdknowledge.com for more on the conflicts of interest and corruption involved.
My one-time systems professor maintained that the Finance Act should always be a computer program. In this case, as others, an advantage of the program is that it can be tested and modified afterwards. This could be useful in many contract examples – but many contracts and agreements are notable for things that are deliberately silent, ambiguous or rest on an assumption. (eg that RofI and the UK are both members of the EU).
I’m not sure the drafting analogy applies at all. The key difference between a legal text and computer code is that code is usually conditional, with IF x THEN y ELSE z constructions. In a legal text all clauses must not be in conflict with each other. In a piece of code, execution of statement 2 might cause statement 55 not to be executed at all. This is particularly true of linear programming but also occurs in OOP.
There is no requirement for lines of code to not be in conflict. The only fundamental rule is that the code should not crash, e.g. due to an addressing error or an endless loop.
However when the code is written the testing analogy certainly applies.
Sir Clive Sinclair is a great pioneer. His products weren’t that robust but the ideas behind them were revolutionary. Except the C5. I never fancied being on the road with vehicle exhaust at face level while being nearly invisible to traffic that could obliterate you.
Ironically – I always have a problem with any proposition starting ‘I am not sure…’ as the author of that statement invariably is quite sure of their view but (for some reason) is affecting not to be. As such I rarely read the rest of the statement.
It is tempting to say that the C5 was an idea before its time, bu the fact of it is that it was an idea of the right time, it was just that society was in denial…
Hah! Ironically, due to a bug (yes, I know why it happened but it’s still a bug) my “end of tribute” tag was stripped from my comment above. There are various ways in which it might be possible to reveal it but that requires me to guess how comments are parsed and why they’re parsed differently from the original text I was quoting. I might have to post several different versions to find out and get it right, if indeed it’s possible to reveal it at all.
The law is the same – common meaning gets stripped out and detailed knowledge of the mechanisms of law is required to decode the resultant legal text.
I wonder whether programming has developed over the last half-century in a way that legal draughtsmanship has not, and whether this weakens the analogy described in the post.
One of the problems with programming statements like GOTO is that they can result in what, as mentioned by another commentator, has disparagingly been called “spaghetti programming”. If you allow program control to jump around without constraint then the only way to figure out what might happen is to follow the thread of execution.
An early development in programming theory was “structured programming”, used in languages like ALGOL or Pascal. This replaced, for example,
IF xxx THEN GOTO yyy
(where yyy was a particular location elsewhere in the program) by a self-contained structure
IF xxx THEN yyy ELSE zzz ENDIF
A further development of this was “object-oriented programming”, or OOP,,again mentioned by commentators, where encapsulated “objects” were used to perform particular functions. Each instance of the object had “properties”, which expressed its state, and “methods”, which allowed you to manipulate the object.
You didn’t need to know what was inside the object, and indeed an improved algorithm might improve the object’s performance (say, in terms of speed or memory use) without affecting its properties and methods.
So now, when you open your web browser, or your spreadsheet, it appears (or can appear) in a “window”. The window is an object which deals with displaying text and images on your screen, and is summoned by the browser or spreadsheet as appropriate.
If you are preparing a complex software package, your need to understand the working of the system “as a whole” is now reduced, because you need only understand the published properties and methods of each object that you use.
These theoretical advances in software development have perhaps limited the analogy between legal drafting and modern computer programming.
To an extent, the law got there first in that it is constructed around very well defined concepts and items, refined over years and understood by lawyers in a very clear and particular way.
OTOH, Kurt Gödel. Real-life is messy.
Awaiting the day when a supreme court decides that a case is undecidable
GOTO’s certainly useful but does need to be used with care, and sparingly.
Now, if you’ve ever looked at Intercal, you’ll know of its COME FROM statement… I would not be surprised if there are any legislative equivalents of that out there.
I had to go through a contract with the CEO of a software house and the way his eyes glazed over told me that he hadn’t looked at it at all. There were only a couple of problems relating to clarity of defined terms; I explained to him that defining a term in a contract was like declaring a variable in code and you could almost hear the penny drop. He suddenly got very keen to run through the whole thing and sort it out because that was the stuff he loved doing. I often think I should have stuck to coding…
I love it.
De mortuis nihil nisi bonum.
A long time ago I made a minor contribution to The Computer Misuse Act. This was enough to cure me of lawyers and politicians forever. Then something to do with computer security – a horrible messy business – just hope nothing goes wrong on your watch.
Even back then there were enthusiasts for introducing software techniques into the law. Although I suspected the lawyers were not keen and the software types – well the less said. I went in another direction and retired from all that.
Software production has improved vastly in the last 40 years – at least some of it has. The enthusiasm for APPs seems to have opened up a wild west where the surface gloss may look all right but underneath no one knows what is going on. A visit to Bruce Schneir’s site gives a hint of the possibilities.
Github – an open repository – has some very good and not so good offerings. The better offerings include automatic test cases, controlled building tools and a record of updates and problem areas – and it is free. Perhaps the lawyers would like a free source of draft contracts and Acts of Parliament etc. If only to learn how good/bad their own efforts are.
As for computer languages, you haven’t lived until you have tried FORTH or LISP (not for too long though – that way madness lies).
As John Carmack once said: “Contract law should be turned into a formal language, with static analyzers and solvers. More Haskell, less [Perl].”
https://twitter.com/id_aa_carmack/status/489443570655301632
For context:
– Haskell is a statically typed (checks are performed by the compiler), purely functional programming language, developed and designed by a community of Computer Scientists, used heavily from Programming Language Theory research.
– Perl is a dynamic language, meaning a lot of checks are perforemed in runtime. It is designed by Larry Wall, a computer programmer with background in linguistics.
Interesting. I was just wondering if you could create a “legalese compiler” that could scan for failings such as invalid or conflicting statements in the “code”.
It might be interesting to look at something like BDD and Cucumber where the idea is that system behaviour is defined in terms that a non geek can understand and then mapped to tests written in a programming language like Java or Ruby.
Interesting post, made me wonder how this fits with international treaties where perhaps more political/diplomatic art than logic … E.g. praise for GFA for its, presumed deliberate, ambiguity
I was struck by Matthew Waddington’s recent blogpost on the political pressure for ambiguity where laws are negotiated by non-subordinate legislators, as in the EU and the USA, rather than handed out by a parliamentary government, as in Westminster:
https://legislativedrafter.wordpress.com/2021/09/12/vagueness-ambiguity-in-legislative-drafting/#:~:text=intentional%20semantic/syntactic%20ambiguity
I’ve always thought a better comparison is between computing standards documents and legislation, particularly when trying to explain to programmers why it’s not just a simple matter of ‘following the law’. Interpretation is important in both cases, and not necessarily consistent between implementations/applications. It’s a balance between brevity and completeness, along with the need to actually be able to enumerate all relevant situations.
A very apt comparison. In the middle of the Venn diagram of programming and legal texts you alsobhave standards documents (for protocols, interfaces, etc) which are often referred to as a contract (between hardware & software, or client & server)
All written in natural language for human interpretation but requiring the precision necessary for interoperability between different systems. Usually starting with definitions of seemingly everyday words like SHALL, SHOULD and MAY.
Programming and the law are simuntaneously very similar and very different. They’re similar for the reasons outlined above. But they’re different in that a program is executed by a machine (possibly purely theoretical) which behaves in an exact, predetermined way, while laws are “executed” by people who may reinterpret wording in unpredictable ways.
Part of this is that laws are written in natural language, which is frequently rather fuzzy. An example of this is the sorites paradox, so if a law forbids you from having a heap of sand outside your house, how many grains of sand does that take? In computing, such a thing would be defined as part of the language (usually including the possibility of zero grains, which will then lead to completely predictable meaning which is highly counter intuitive). This means that courts must decide on a meaning, and to avoid chaos we must generally follow precedent, which then means that a law as implemented cannot be truly understood without knowing the relevant precedents, which is rather unfortunate when some of them lie in the future!
It is easy to think that the formalities of computing makes things easier to understand and predict, but that’s not really the case. They’re just different. For example, Rice’s theorem shows that it is impossible to determine many properties of a piece of code. An example of this is you have two pieces of code and you want to tell if they both do the same thing. It is impossible to write a program which, when given an arbitrary pair of chunks of code, it will be guaranteed to correctly say they behave the same or behave differently. For people who suggest that tax law be written as code, this means that theoretical analysis of the laws of two countries might be unable to tell if they had the same effect.
My knowledge of legal drafting is far more limited than my experience of computer programming, but I think that legal drafting is more akin to technical specification than to computer programming itself.
In technical specification, the thing being specified tends to be somewhat simplified to convey the core parts of the solution. This might mean very clear algorithmic text for certain important things, but more vague statements for others. I think the HTML spec is a fairly good example of this: https://html.spec.whatwg.org/multipage/
When the programmer actually comes to covert this into computer code, they have to resolve ambiguities and unthought of details as best they can, in order to get something that works both for the user of the program and with the cold logical reality of the computer.
They also commonly have to deal with the existing program that they are modifying and the fact that it may not match assumptions made in the specification.
In some ways all of this seems more similar to what legal professionals and the public have to do when applying the law to real life situations.
In summary, legal drafting and technical specification seem to deal with a simplified view of something, as a necessity of writing something “small” enough to be comprehended and agreed upon.
Computer coding and the application of the law have to deal with the actual reality of that thing.
I know very little about legal drafting but a fair bit about programming. I guess there’s a shared need to think, “And what if the user tries to do THAT?!?”
Yes, and in the case of programming there’s very much a need to think “what if a programmer building on top of this work (who may well be yourself) tries to do THAT?!?”
I don’t know if there are equivalents in law – e.g. drafting contracts or other legal documents in a way which will prevent costly mistakes by future revisers of those contracts.
years ago I’d thought software could be used to encode/decode contracts, I remember speaking to a lawyer at a biz event who said he had some that just underlined changes in a contract file, it was reading this book about music biz contracts that gave me the idea, capitalised words like “Sales” not meaning what a layperson might think, but being a term defined at the back
Legislative drafters like me, and other people who understand computing, are looking into this right now. The OECD produced a report recently on “Rules as Code” – https://oecd-opsi.org/projects/rulesascode/ . The modern disciplined approach to legislative drafting in Commonwealth countries comes close to a “controlled natural language” – so much so that Prof Bob Kowalski of Imperial College is creating “Logical English” as a programming language which he says was inspired by the way legislation uses English.
Deliberate errors to catch copyright theft.
https://en.wikipedia.org/wiki/Fictitious_entry
OS maps have errors. How many are deliberate?
If then
….
if then
….
if then
….
if then
….
else
Define
if Properly defined problem
Properly defined stuff happens
else
Shit! We hadn’t thought of that!
abort, abort, abort!
Go to court!
enddefine
endif
(the ‘else’ is where the catch-all comes in. Catch-alls can be unspecific, but when the problem is well defined it is less likely that the ‘else’ will end in a major problem).
(Just a thought or two on where computer programming and legal stuff may have common ground. Possibly).
Thanks Mr Green many thanks indeed, I am neither a law person nor a professional Programmer, my javascript is barely enough to tweak some functionality in the Adobe Programms I use at work, but this comment thread has brought back so many memories. A really joyful and educational read so thanks to all who had something to say about the topic and to you again for posting the topic
I was going to say “not another comment on law and code but.. ” here’s a thread with a great story which will resonate with anyone old enough remember the early days coding at home
https://twitter.com/shahidkamal/status/1438891569868910596?s=20
Now that I think about it, it highlights the relative accessibility of the law and code to would-be practitioners (often with adverse results in IT security and reliability!).
I have programed computers for many years – and as my career progressed I have bee required to read and understand almost all the types of legal document that would impact on a company.
As well as a requirement for careful analysis of logic and precedence,cComputer language processors (compilers/interpreters) are most unforgiving of *any* errors in punctuation or errors of syntax – in some cases even the number of spaces is critical.
Having been forced to get used to the ways of processors was a definite advantage when it came to legal documents.
Of course, as my previous comment demonstrates, I still can’t type!
The underlying field of study which is the source for both good legal drafting and computer programming is Philosophy, specifically its Logic branch.
With 40 years of perspective, I am now certain that the most valuable courses I studied at university were my Philosophy courses focused on logical thought.
It lies at the root of all good argumentation, drafting and coding.
Also highly useful was identifying and understanding logical fallacies.
May I aver that there is a stronger analogue between legal drafter and systems designers rather than programmers? Specifically, in my field, the work of games system designers.
(The term Game Designer* covers a lot of this, but is too varied and vague a role to help here).
When designing a game system, the designer is defining the limits of the system. What are the actions of note within the system, what is specifically allowed/disallowed, what are the specific rewards/punishments/remedial actions?
What is usually not specified is the exact construction of How these actions should be delivered.
It is the programmers or artists job to define How the system works or the board game players job to engage with the system with fellow players within the defined playspace.
A really well written game design or game manual will tell the reader exactly what the boundaries are and what the rules are without obfuscation or contradiction.
The implementer or player should then be left with utmost confidence that they are creating or playing well.
Board game players, like myself, who enjoy reading and understanding rules and systems are called Rules Lawyers for a reason…
(With the expected positive and negative connotations!)
(cross-posted from Twitter: https://twitter.com/Shar_ds/status/1439850049673076737)
* A good description of the roles here: https://intogames.org/role/system-designer-games vs https://intogames.org/role/game-designer2
Funny I was just reading the judgement on Bailli about Prince Phillips will and it made me think of something similar to this.
There is a safe with a single unknown copy. Data retention policy is to have 3 copies 30 miles apart. Shouldn’t the wills be open and copied to ensure their preservation even if unpublished. They are a single point failure.
As was mentioned in the judgement 80 years is within WW2. So these important papers need to survive bombings, mass flooding and fires etc.
All in a single safe.
Judgement at Bailli: Will of His Late Royal Highness the Prince Philip, Duke of Edinburgh, Re The [2021] EWHC 77 (Fam) (16 September 2021)
Hi David,
Non-lawyer, but particularly struck by your “stress-testing” point. Absolutely agree. Am wrestling again with accusations based on “safeguarding” rules for kids and old people. Very obvious to me that the rules have been written by non-legally trained people, who haven’t done that imaginative stress-testing, and are being wielded by people (teachers, care-home managers) who also haven’t done it, and further don’t understand that a body of rules needs reading as a whole, not just line by line.
I compare that with one of our oldest rules, therefore time-tested – “Thou shalt not kill”. Everybody reasonable can support it as a general principle, but they also support carve-outs – self-defence, protection of more innocent lives (hostage-taking situations) in civil situations, and in military contexts. (In my view, there ought also to be one for where it would prevent unacceptable suffering. That’s not new – it’s the old coup-de-grace concept).
I’m sure you’re right also about programming and the similarities, but personally stuck at the user “Why won’t it do what I want ?” stage.
perhaps worth recalling https://www.tandfonline.com/doi/abs/10.1080/13600869.1986.9966229?journalCode=cirl20