Please select country
Please select your country
Technology has transformed most data based industries, but we haven’t seen much in the way of real innovation in day-to-day legal practice. The overwhelming majority of lawyers still use Microsoft Word and work a lot of expensive people-hours to get things done. This makes lawyers too expensive for many businesses, even where they could benefit from dealing with legal risks.
Lawyers who want to fix this need to learn from software development techniques. Three practices stand out:
- modular design;
- branched version control; and
- layers of abstraction.
Modular design
What lawyers get wrong
Lawyers are bad at modular design. They apply principles of re-usability in a rudimentary way, but it tends to be at a document-by-document level.
If you hire a lawyer to create a software development agreement for you, you’re paying them to open a 20-page template and customise it for you in Word.
Contract templates are long tracts of legalese, full of phrases like: “subject to sub-clause 7.5(a)(ii)” and “notwithstanding the foregoing”. This is a problem if you need to change sub-clause 7.5(a)(ii)--it generally takes specialised legal skills to understand how the change affects the rest of the contract. Developers might describe this problem in terms of dependencies. Cross references create a mess of dependencies scattered throughout the document.
The outcome is that only a trained lawyer can reliably produce a safe, tailored contract from the template. Worse, because customisation is hard, there is an incentive to fit your transaction to the document, and not the other way around. You end up with a choice between a document that is not fit for purpose, or a hefty legal bill.
That is not how re-usability should work.
Lessons from software design
Developers are good at modular design—-we want to make packages of software re-usable.
We understand that each package of code in an application should do one thing, and do it well. We use principles of ‘loose coupling’ so that we can improve or modify one package with a minimum of breakage in the systems that use that package.
Lawyers should do the same with contracts. They should reconceptualise a contract as a bundle of separate modules, rather than a single tract. Like a software package, each module in the contract should deal with one thing only, and deal with it well.
Each module in a contract should be a set of instructions about one commercial aspect of a business relationship. Business people should be able to bolt on relevant instructions, and bolt-off irrelevant ones. The boundary of a module should be the commercial outcome, not the legal issue, because users are making decisions from a commercial standpoint.
A document’s cross-references (i.e. internal dependencies) should be minimised and clearly mapped. Users should definitely not have to worry what clause 7.5(a)(ii) says when they are looking at clause 13.
Branched version control
What lawyers get wrong
Lawyers are bad at version control. At best, they use linear version control, which badly hampers collaboration; at worst, versioning becomes a free-for-all.
Here’s a common scenario. A law firm creates a template for a software development agreement. One lawyer uses the template to create an agreement for a developer, so their version ends up biased towards the developer. Another uses the template to create an agreement with a customer bias. Another creates a balanced agreement. They may or may not provide a copy to a ‘knowledge management’ team, which may or may not generate new templates.
In the end, the firm ends up with ten versions of the same template, riddled with inconsistencies, spread across shared and non-shared files. It is more or less impossible to keep them all up to date, or to keep track of how they differ from each other.
When lawyers need to create a custom document, they waste time tracking down the templates they need and cutting and pasting from multiple sources. Again, cutting and pasting is beset by dependency problems. There is always a risk of cutting and pasting something without bringing along something else that is essential in order for it to work (like a definition or a cross referenced section).
Once again, the result is that only lawyers can reliably customise legal documents. This approach replicates work, wastes time and money, and allows valuable data about use of the tool (the contract template) to be lost.
That is not how version control should work.
Lessons from software design
Developers are on a totally different level with version control.
Coders use git to allow multiple collaborators to contribute to a project, which is as simple as creating a pull request. Coders take this as a given, but most lawyers have never heard of git.
That needs to change. Combined with a modular approach, git could solve a lot of the problems lawyers have with managing their templates. Rather than creating whole new contract templates for every permutation of a software development deal, and then separately updating each one, lawyers should maintain a series of modules under version control, which can create different commercial outcomes. They would then create documents, like software development agreements, by bundling together the relevant modules.
Changes should happen at the level of the module. This approach would keep templates consistent and centralised. Commits, pull requests and merges would make it much easier to keep track of changes, and much easier to implement updates across a whole set of documents.
Layers of abstraction
What lawyers get wrong
Lawyers are bad at 'abstracting away' complexity. The evidence: contracts are usually painfully difficult to read and understand (even for lawyers).
In legal documents, far too much specialised, technical language lives in the user-facing, top layer of abstraction. Contracts use long swathes of legalese to convey a simple message like, "customer will own IP in the software". The legalese is usually there for good reasons, but it doesn’t need to clog up the top 'user interface' layer.
There are some exceptions. Rather than repeat the same phrase multiple times in a single document, for example, lawyers will capture it by defining it once, and then using the defined shorthand throughout the document. A contract might use the shorthand, ‘IP’ to refer to a long list of rights including copyright, patents, trade marks, confidential information, know-how and so on.
But there is an archaic, paper based, set of conventions about what lawyers will and won’t abstract away from the user interface. It is ok to define a concept like ‘IP’. But it is considered bad form to put actual instructions like, "customer represents and warrants that customer owns the IP", into a definition. Perhaps this is because it requires other lawyers (the only people who currently spend much time reading the instructions) to constantly hop backwards and forwards between definitions and the main body of the contract.
Lessons from software design
Developers are good at abstracting away complexity. In the end, software runs on 1s and 0s, but most developers work at higher levels of abstraction with languages and even frameworks.
Lawyers should think about the instructions in contracts in the same way. Conventions about abstraction should not be dictated by what works for paper documents. If you can view a definition with a click of the mouse, why not just leave a simple outline of key commercial outcomes on the top layer, and abstract away the confusing detail?
In the examples below, red text represents the legal function call and blue text stands for the legal function’s arguments. The substitution of arguments from the "top layer" into the legal function is governed by interpretation provisions in the contract.
| Top layer (calls the function) | Second layer (the function) |
|---|---|
| The Developer Transfers IP Ownership of the Code IP to the Client. |
Moral Rights means... (another 20 words) Intellectual Property Rights means... (another 150 words) |
In short, we've taken 300 words of technical legalese and reduced it to 12 words for most of the people reading the contract.
Non-lawyer users only need to see the top layer (left). On the right is what coders would call a ‘function’: a detailed, replicable set of instructions. This legal function can sit behind the short summary, in the layer below. And if we think of the top layer (left) providing the 'arguments' for the legal function (right), it can be reused in multiple contexts.
The Customer Transfers IP Ownership of the Code IP to the Developer.
The Developer Transfers IP Ownership of the Design IP to the Customer.
If you don’t use abstraction, the stuff on the right-hand side of the table above proliferates. Again, non-lawyers are hard pressed to make sense of it, let alone modify or customise it.
Conclusion - it's all about data structure
Lawyers and developers are both in the business of structuring, re-using and updating complex sets of instructions. Lawyers should follow developers and use the best techniques for managing the informational complexity in that process.
As we work with these tools at Treescribe, we’ve noticed that we spend a lot more time talking about data structure than the law. We think transactional law will become a specialised data science discipline. We’re optimistic about this – the new tool set available to lawyers will open up new ways of doing business and structuring deals.
