Skip to content

Why Computer Scientists and Legal Professional think so differently...

Over the years, teaching to and working with both groups, I always wondered, why computer scientists and legal professionals think so different.

Especially when teaching legal technologies, this can be a problem. It is not only that both groups do not understand each other, in some cases they are not even aware that the disciplines and methods used by the other group exist at all! This can be a problem when a computer scientist teaches legal professionals or the other way around. As a result, learning objectives are not reached and confusion, misunderstanding and frustration remain.

As a result of years of experience teaching to both groups, the author thought it to be useful to list the differences. The table below provides a generalized overview of the most important differences between lawyers and computer scientists. Off course, one should be careful generalizing, but by naming these differences explicitly, they can be addressed better.

 

Computer Scientists

Legal Professionals

Thinking in processes.

Thinking in individual cases.

Look for common ground to be able to automate.

Focus on the differences and emphasize these.

Standardize as much as possible.

Want to be able to use their "lawful legal discretion" (discretionaire bevoegdheid in Dutch)  at all times and are therefore often against any form of workflow or computer driven process automation.

Measuring quality with quantitative (mathematical) methods and values.

Have no tradition of quantitative quality measurements. Have less affinity with arithmetic, let alone mathematics and statistics.

Describe solutions, problems and algorithms in deterministic concepts, flow-charts, computer language (pseudocode) or formulas.

Describe algorithms, formulas and processes in (often) ambiguous natural (human) language.

Avoid ambiguity where possible.

Consciously build in ambiguity for future contingencies and unexpected cases.

The 80-20 rule is a good starting point: 80% of functionality for 20% of cost and time.

80-20 rule does not work for legal matters.

At the end, deliver a fully working solution.

Have the obligation to implement "best efforts". No guarantee to deliver a "win".

Follow principles of “user-friendly design” in software and user interfaces.

The need for design thinking is not commonly accepted or applied by legal professional.

Make experimental, alpha, beta, and other intermediate releases through iterative processes. Iterate gradually toward the optimal solution. Agile work is the standard.

Only deliver when everything is finished as much as possible. Trying to do something right the first time. Have no tradition of iterating or working Agile.

Often sign contracts without fully reading it: “contracts are written by lawyers, for lawyers” not for me…

Spell legal documents before they even consider signing them.

 

The above differences run deep and start early: as early as the basic training, computer scientists and lawyers are thought a completely different approach, a different way of working, and even a different way of thinking.

Bridging these differences starts with recognizing them and then taking them into account in LegalTech education. If you do not, teachers and students will not understand each other, and the learning objectives will not be reached.

 

 

 
, , ,