- Author and manage text as code, not data or “documents”.
- Work with source code, not compiled code.
- As “Lists” of key/values.
- Which reference other Lists. (Modularity, versioning, semantic web.)
- In a declarative layer on top of other resources. (Lisp, Python, a database, etc.) Integrate with graphs.
Legal texts will iterate to become as efficient as stock markets (bazaar, not cathedral) and general purpose, distributed.
Also good for kids. Commits as 3-ring binder of all your work, in context, forever. Shakespeare and the history of physics a few hops away.
One of the strategies of the Ruby on Rails community is described as “convention vs configuration.” The idea is that a complex framework can be built in a lot of different ways, and it makes sense to resist the instinct of designers to keep things general. The designers create convention by picking ONE out the dozens or thousands of ways that a thing could be done. That choice might be a bit wrong and might require correcting, but it accelerates the process and gives people a target to work with or contest. It has been one of the reasons for the great success of RoR.
Word processing as a vehicle for legal docs can be seen as the ultimate in configuration. One is free to change any character, any order, any format. In fact is should be called character processing.
As a reader, one is endlessly reprocessing old ideas in new configurations.
Modularity provides us with a way to use convention as the default and configure only as needed.
Odd that agreements, which are known in French as “conventions,” so often are done by configuration.
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.
That seems 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 they can be arranged 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.