General good wishes

[Joe Reevy]

I remember about 20 years ago I did a talk and compared the way law is done now to how a Mercedes was built in 1900...all highly skilled, experience needed with lots and lots of attention to detail, cost more than an average person's earnigns in half a decade and the result was something massively inferior on an absolute scale to the runaround I paid cash for brand new.

I know it had to come to pass and it is to everyone's benefit* that it is starting to happen at last. I wish you well.

As you have new exciting things to say, please make sure we're included (email directly to j...@legalrss.co.uk is best) and we'll tell the UK legal population!

Kind regards,

Joe

* to my lawyer friends who doubt this I always ask if they'd rather be in the airline business with Wilbur and Orville or now...

[Meng Weng Wong]

Thanks!

Your analogy finds an echo in Darmstadter's Precision's Counterfeit:

Complicated things have more ways to fail than less complicated ones. A lot more can go wrong on a modern Boeing 777 airliner, for example, than a 1930s-vintage Douglas DC-3, and a lot more on a DC-3 than on Lucky Lindy's Spirit of St. Louis. Yet the 777 is more reliable (not to mention faster and more comfortable) than the DC-3, and the DC-3 in its turn is superior to Lindberg's Spirit.
   Legal drafting is largely a cottage industry, and most legal documents are—to borrow a trendy term from the gourmet-food world—artisanal. Even for large international firms, documents are usually produced by small teams.
   For the products of non-legal engineering, such as automobiles and aircraft, information regarding defects flows up from consumers and repairmen to manufacturers and regulators, is compiled in databases, and flows back down as technical bulletins and recalls. But the dispersed production of legal documents, along with client confidentiality concerns, the threat of litigation, and cost considerations may make such a model unworkable for legal products.

One way to frame the question is: how do we shrink the learning loop?

In Lean Startups, the build->measure->learn cycle is the engine of improvement. The quicker you can do it, the faster your startup finds its market.

In software, the code->compile->crash cycle is the inner loop. As Avi Freedman once said to me, "You learn when you make mistakes. Computers are great because they let you make mistakes fast." (He may have been quoting Mitch Ratcliffe).

Moore's law quickened that loop. In the old days, a computer cost $5 million, so programmers had to share, trudging uphill both ways in the snow to submit their batch jobs on punch cards. To get the results they had to put their boots on again the next day.

In legal, the legislate->execute->litigate cycle is even slower and more expensive than mainframes. If you had to order a $5M computer every time you wanted to run a program, why, programmers would still be quoting precedent from decades ago: "Hey, we really shouldn't call that function, because in 1993, on a Sun Solaris Circuit, when NASA tried calling that function, it didn't work as expected, so we'd better not either."

We need to catch errors at compile-time, because run-time errors are called litigation.

[Virgil Griffith]

Can we get a PDF of http://www.jstor.org/stable/25758526 ?

-V

[vi]