Why is our legal system not designed and run on engineering principles?

In a recent blog article, Professor Anthony Finkelstein, Dean of Engineering Sciences at University College London, commented: “I simply cannot understand how disciplines that struggle with complexity – law being a case in point – are able to do without [diagrams]. So many problems could be better explained, so much more material readily assimilated, and the route to analysis and problem solving smoothed, if a diagram were used.”

This prompted several memories of situations in which IP Draughts has worked with colleagues who have an engineering training, both lawyers and non-lawyers.  In IP Draughts’ experience, a combination of legal and engineering thinking can be a very powerful tool in problem solving. Just having one or the other discipline, though, can lead to mutual bafflement when lawyers and engineers mingle.

A good example of the combined approach can be found in the structure and content of a legal textbook, Chartered Institute of Patent Attorneys’ Guide to the Patents ActsIP Draughts has reviewed this book in the latest edition of the Journal of Intellectual Property Law and Practice.  In his review, IP Draughts comments:

The CIPA Guide is more like an instruction manual, written by engineers for engineers, than an extended essay written by classicists for classicists.  The approach of the CIPA Guide is unusual among law books, but well-suited to the area of patent law.

An example of mutual bafflement is an experience that IP Draughts had over 20 years ago, in a conference room in San Francisco.  IP Draughts was negotiating the terms of a trade mark licence agreement with a roomful of computer scientists from about a dozen computer companies, including IBM and some other large players.  IP Draughts’ client was a trade association that had developed standards of “open-ness” for UNIX-based computer systems.  Companies that met the standards were to be permitted to apply the trade association’s branding to their computer systems, under the terms of this licence agreement.  The companies were very keen to ensure that the terms of the licence agreement were appropriate.

During a line-by-line negotiation of the draft licence agreement, which took several days, one of the computer scientists piped up to complain that IP Draughts had included a “forward reference” in one of the clauses.  In other words, the clause used a defined term, but the term was not defined until a later clause.

In [traditional?] computer programming, if you use a defined term before defining the term, the program won’t work – it will “crash”.  Fortunately, judges have more mental flexibility than a computer, and can look forwards and backwards.  IP Draughts explained this to the computer scientist and the discussion moved on.  This small incident reminded IP Draughts that contracts and computer programs have many similarities, but also some significant differences.

In IP Draughts’ experience, engineers sometimes express frustration that a lawyer cannot say with certainty how a contract term will be interpreted by the court.  Sometimes, this leads to unfavourable comments about the quality of judges and the desirability of replacing them with computers.  Usually such comments (and IP Draughts has heard this type of comment on several occasions) overlook the human element – not just the variability in outlook (and, dare we say it aloud, quality of contractual analysis) among judges, but more importantly the human element in how the parties to a contract behave.  Sometimes, neither party complies strictly with their contractual obligations, and the task of the court is far more complex than just “cranking the handle”.  Issues such as waiver, good faith, misrepresentation, mistake, failure to comply with contractual procedures, variation by conduct, and the rest may have to be considered.  There is also the problem that contracts are based on words, and words can have many subtle or not-so-subtle variations in meaning, depending on usage and context, as the recent criminal trial of John Terry (former captain of the English football team) shows.

Coming back to diagrams, IP Draughts is in favour of anything that may aid the parties’ understanding of their legal obligations.  He sometimes include mathematical formulae in contracts, eg in payment clauses, but has not seen many diagrams being used.  In principle, there is no reason why they should not be used.  If flow charts are used, there may need to be a definition or cross-reference to any protocols that are used in the flow chart, eg as to the significance of the shape of an individual box.  If both text and a diagram are used to cover the same point, the contract should make clear which takes precedence, in case they vary in meaning.

2 Comments

Filed under Legal practice

2 responses to “Why is our legal system not designed and run on engineering principles?

  1. Some (admittedly odd) programming languages can cope with forward references.

    There’s a “late binding” problem – until you know what a particular definition means (or the value of a variable) you have to create an every more complicated dependency structure, in your mind or in the computer’s memory, which is later resolved when you have the value.

    Now there are good reasons for doing this, but it can clearly cause problems.

    In programming a forward reference definition is not quite an undefined term. In a sense the definition itself contains semantic hints. You do not expect to see a term like “Charged Property” to be defined later on to mean “any tree of the genus quercus”. You have an idea what it means, so your late resolution problem is more confined.

    So, the extent to which a forward definition is problematic may depend on the degree to which it is unexpected. In statutory material one sometimes finds some quite surprising definitions. If the definition is too long delayed it becomes very hard to understand the statute.

    Anyway, as always this is fascinating stuff. I’ve programmed and drafted contracts for money so I think I have a fairly good appreciation of the difference between the two.

    I think there are some good program analysis techniques that could useful be used in drafting, particularly of statutes. “case analysis” comes to mind. “If a, then X or if b, then Y” is problematic if it ignores the possibility of c.

  2. Software people can be a world unto themselves, and some members of the traditional engineering community (electrical, civil, chemical, mechanical, etc) aren’t comfortable with the very concept of a “software engineer”. But that’s a separate debate, although it occasionally has a legal aspect in the sense of which engineers can or should be licensed and who has a right to style himself an “engineer”.

    I would say that most professional engineers are familiar with uncertainty. Philosophically they know of Heisenberg, and practically they know that an engineering design is almost always a dynamic trade-off between desires and affordability. The same could be said for the ordinary NDA, which occasionally I’ve seen as five pages of text! Keep asking any nuclear engineer the “what if?” question and you’ll get answers not unlike what a client hears when asking his lawyer a series of “what if?” questions.

    Many engineers are more comfortable with mathematics and graphics than the written word, in the same way that many lawyers aren’t comfortable with calculus.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s