Positively Glorious!

In possibly the most unexpected analogy ever, Jean-Paul Voillequé, in an attempt to become universally hailed as Portland’s geekiest lawyer, gives un an interesting link between coding and law:

“When you read a programming manual, For Dummies or not, it typically states a set of design principles. Among these is the notion that code should flow cleanly, be organized, and to the extent that it is possible, tell the story of what’s going to happen if I compile the program. A contract is fundamentally no different, except the machine you’re compiling the program on is usually a court of law, regulatory schema, or (often) another body of code, like a default statutory scheme. The contract receives inputs and outputs results according to the scheme.”

This absolutely rocks! The anthropologist in me is seeing all sorts of linquistic uses for such a metaphorical device. In both directions. It could be illustrative for you as a lawyer to see things from a programmer’s perspective, but it could also be illustrative for us programmers. One interesting thing I see is precedent.

It’s a bit of a stretch, but precedent has an analogy in the Object-Oriented coding sphere because code re-use is not only acceptable, but the preferred path.

Algorithms as Precedent

When I develop an algorithm, I am not only developing a solution to a specific case, I am setting a precedent for how an algorithm can perform in that case, how it can handle- or abstract- information. In fact, there are entire undergraduate programming classes, with accepted principles firmly developed, on how algorithms should be designed. Something like a case library, if you will.
When I develop an algorithm, I am setting a precedent for how an algorithm can perform in that case

One algorithm (precedent) is the way an array is created as a statically sized object and then populated and used. For much of early programming history, this was the accepted practice. This led, of course, to buffer overflows in many cases. Eventually, there began to be new cases (languages and libraries) where dynamically sized arrays were possible and, in given situations, a new precedent was set. Good programmers, who understood the situation and knew the previous casework, could pull out a dynamic array in a given case to prevent problems.

Of course, precedent can have drawbacks too, because there are times when it is not appropriate. Just as dynamically sized arrays are not always the best solution, any given algorithm designed by a programmer may not be applicable in all cases. Unfortunately, those programmers who do not understand the situation, and are perhaps not fully knowledgeable about the previous casework, might try to use them anyway.¹)

The is a major concern, because the precedent set by any given algorithm will likely be carried into another program at some point, regardless of the situational context of the original. It’s likely that the re-used code will carry with it a precedent for handling a specific situation which is not useful, or intended, in the new situation. Nevertheless, it has worked in the past, and has become “en-coded” in a sense into the individual’s or programmers’ books.

Programmers do this all the time. We write a piece of code quickly, never intending it to be used “as is” in another situation, yet there we often find it, sometimes years later, being used as a fundamental principle in an orthogonal case.

A Programming Example

I’ll illustrate an example of this concept from the programming world. ((No code (it’s not open), so I hope a narrative suffices.

I had an algorithm that was designed to calculate time under very specific circumstances. Basically, the idea was that we needed to calculate the time of day based on the solar year and use that calculation for a further calculation of the tides. In order to do this calculation, we used information and equations from the naval observatory, calculated the solar position to get the solar date (somewhat different than the calendar date, as it turns out), and used the solar date/time to calculate the exact tidal signature. The class was called something like “CalculateRidiculouslyAccurateDate” and the comment was something snarky like “Because ridiculously accurate dates are *always* better than slightly accurate ones.”

My intention was never that this class would be used to calculate dates except under very specific circumstances.

Now, this was a complex calculation, and it required a large amount of computation to achieve a relatively simple result. We felt it was necessary at the time because we were trying to calculate the tide to the centimeter. My intention was never that this class would be used to calculate dates except under very specific circumstances. Thus, I was very surprised to find the method in another program, where it was basically cut and pasted with a comment something like “Calculate a really accurate date.”

The interesting thing was that my method was ridiculously complex- far too complex for the later use. Grabbing the system date would have sufficed, and used a lot less processing power. However, the mere use of this methodology previously was enough to encode it in the organizational lexicon. The precedent had been set that, when getting dates, completely accurate dates are desired, so the programmer grabbed the most accurate date calculation method he could find. This ended up being something that was unnecessary and never actually intended.

A Legal Example

The legal example I have is explained in a recent New York Times article. The article explains how the supreme court’s decision in Bush V. Gore was never intended to set a precedent. Here, the supreme court, in ruling on a very specific situation, is forced to make a decision that could possibly have ramifications external to the case. In the decision, they state explicitly that the ruling is not intended to set a precedent and is specific to this case.

Nevertheless, it has been used, encoded in the lexicon, and is thus being pulled for use in cases where it was never intended to have sway. Here, like our programming example, we have a piece of legal code being pulled from context because precedent overrides, for lack of a better word, usability or appropriateness.

Coda

I’m not a lawyer, so my understanding of precedent may be a bit off. Furthermore, my analogy of algorithm as precedent is, admittedly, a bit of a stretch. Still, I find the comparison between law and code a very interesting and useful one. Looking at both as “a set of design principles” which contain a narrative description of “what’s going to happen if [we] compile the program” is A Good Thingâ„¢.

Read Jean-Paul’s original article: Drafting as Coding | JPV PDX, and bring on some code examples of your own. The idea does have legs. I’m interested to see how far it runs.

1. The hope here, is that a good compiler (read: Judge) will call them on it ! [↩]