Some claim that one can “find” “a” meaning in a text. I usually find that I’m bombarded with possible meanings. The claim is that by carefully parsing words one will arrive at the one true meaning. And that meaning “is” or “is as if we got to” the meaning “intended” by the writers. They got to or started from that meaning.
This claim is made in a number of contexts, notably in connection with interpreting the language of a contract or constitution.
Perhaps it is dyslexia speaking, but that has always seemed off of the mark. When I write, the words never seem right, and when I read, good writing seems like a good tour guide — the words keep me looking in the right direction.
When I learned my second and third languages, it was viscerally reinforced that words aren’t the same thing as thought. You need to move the English out of the way to let the French or German words present themselves so that consciousness can pick and arrange them into a construction that fits the rules and will point another person in the right direction.
But, it might be argued, even if the words come after the thought, maybe they still subsume it. How can you talk about a thought except in words? Aren’t the thought and its words consubstantial, at least practically speaking? Speaking of which, translation provides a nice example that pushes back on this notion.
The multiple versions of a legal text, for instance the clause that accords the power to arbitrate disputes to the ICC, can be written in different languages. Do these mean the same thing? Did the authors “intend” that they mean the same thing? Does their “intent” bridge the nuances of language! What is “intent” in the various languages. Do we parse each in its own direction or think of them as having a collective intent?
Everyone reading this is aware of the parallels between writing software and doing legal documents. As a text creating and handling exercise, software is considerably more demanding than law. So developers have developed techniques and tools for managing the complexity. Those techniques are transferrable into the legal domain, sometimes with a bit of adaptation.
This post focuses on a higher level, on an approach to managing the effort of development.
A “scrum” is a piece of an “agile” development effort. Agile draws on “extreme programming” thinking developed by Ward Cunningham, a friend of the site.
Agile is part of “lean” start up and related to “lean” manufacturing. (Anyone who is out there and has read the book, please let me know if “Lean Forward” leans in the same direction.)
All these respond to the fact that software development (and starting up a company) are non-deterministic. Planning is essential but plans are soon worthless. (Eisenhower put it more starkly.) So, one should do the productive part (planning) rapidly and dispose of the worthless part (plans) often. (Can someone contrast Jack Welch’s complaint that when he took over GE there was lots of planning but no plans.)
The focus shifts from a paradigm of correct thought (orthodoxy) to one of thinking.
Even thinking can be aided by a methodology, especially group thinking that hopes to escape group thought. In another domain that might be Buddhism. In software it’s a scrum. This scrum of an idea counts as a post.
Ari Hershowitz responds to a Quora post, discusses the disincentives that private practice lawyers face for document efficiency and mentions CommonAccord. While agreeing with his observation that the innovation is coming from unconventional legal companies, my experience is that incentives play only a small part.
I think the key issue is cognitive. The incentives argument over explains and under explains. It doesn’t explain the rather considerable efforts by some law firms to automate areas of document creation. The tools of Contract Express, Exari, HotDocs, BrightLeaf and the like are being used. It also doesn’t explain why in-house counsel, CIOs and even the open source community (e.g., SPDX, Oasis-Open) have not really solved the problem.
The cognitive issue is failure to notice that legal docs are textually the same as interpreted code. There is a similar movement in documentation for software. Dan Allen (@mojavelinux) says treat your documentation like code.
“REST” is a paradigm of web interaction that … let’s GET that from Wikipedia. Basically, it is good manners for guest and host at a site (“rest stop”?) on the information highway. The power of REST is parsimonious focus on a few principles.
Incrementing the state of our relationships can be understood as being like blog posts. Create, modify, delete. Though both modify and delete should also be done as creates: create a modification and create a deletion. Having created a relationship and then ended it is not the same as it never having existed.
As you READ the previous paragraph, PUT “graph node” in the place of “blog post.”