10k foot:

  1. Author and manage text as code, not data or “documents”.
  2. Work with source code, not compiled code.  
  3. As “Lists” of key/values.
  4. Which reference other Lists.  (Modularity, versioning, semantic web.)
  5. 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.

A short intro to a better way to do law.

Excellent list of improvements in managing contracts.

Commitment Matters

Many will be familiar with IACCM’s work to identify the scale of value leakage from contracts and to identify the major causes for loss. Unless you work in the Construction and Engineering sector, you may not be aware of similar work undertaken by international consultancy EC Harris.

At this week’s IACCM Asia Conference, Mike Allen (Partner and Regional Lead at EC Harris) presented ‘Global Disputes by the Numbers – and Contracting’s Role in Avoidance’. To an even greater extent than IACCM’s research, Mike’s work has pointed at weaknesses in contract management lying at the heart of most disputes – and therefore highlighting that improvements in contracting competence can potentially yield a rich return.

In concluding his presentation, Mike talked about a number of the improvements he is observing among market leaders. These reflected many of IACCM’s conclusions and I thought I would consolidate to produce a ‘Top Ten’ –…

View original post 85 more words

An explanation of how money clears the banking system. Didactic in the good sense.

Richard Gendal Brown

Twitter went mad last week because somebody had transferred almost $150m in a single Bitcoin transaction. This tweet was typical:

There was much comment about how expensive or difficult this would have been in the regular banking system – and this could well be true.  But it also highlighted another point: in my expecience, almost nobody actually understands how payment systems work.  That is: if you “wire” funds to a supplier or “make a payment” to a friend, how does the money get from your account to theirs? 

In this article, I hope to change this situation by giving a very simple, but hopefully not oversimplified, survey of the landscape.

First, let’s establish some common ground

Perhaps the most important thing we need to realise about bank deposits is that they are liabilities

View original post 2,350 more words