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.