The Common Law and Agile Development

Matt over at 37signals wrote this:
http://37signals.com/svn/archives2/functional_specs_subvert_the_hierarchy_of_nature.php
It's basically a comparison of the issue of creating functional specs vs agile team collaboration with the issue of code law vs common law.

"So what’s code/common law got to do with it? Here’s a very basic explanation of the legalese: Code law is based on a system of codified written laws. The rules are set and that’s that. Common law, on the other hand, is based on a series of ongoing decisions (like the legal system here in the US).

"So we’ve got a rigid system that’s set in stone vs. a flexible one that reacts and responds to real-world situations. Sounds familiar, eh?"

This is my response:

You've touched on something that goes extremely deep, Matt. Code Law has a powerful tendency to supplant common law in all but the most vigilant cultures. Written laws, process documents and specifications all have a place AS AN ARTIFACT OF AND ENABLER OF COLLABORATION. Supplying too much documentation can turn the best of teams into drones.

Code Law also creates the illusion of power over chaotic forces
that require empowered, immediate intelligent responses that are specifically subverted by the presence of written rules. Coded Law takes natural forces of human collaborative psychology and attempts to manipulate them with what are ultimately words (and maybe some pictures).

I was recently asked to create an entire process out of the box before I even had a chance to hire the team and while core definition work was taking place. These were business processes and the total number of processes needed could have been brought together by a team in a matter of days. A former boss of mine (who owned a consulting company that was so chaotic that the mere application of common sense made one look like a genius) insisted on defining all the processes up front. I tried to explain what that would do to the dynamics of the team that had to execute the processes but he didn't even begin to get it.

This is the typical problem - people with power want to feel safe from threats that can rip through a phone book worth of paper at will. They want to read something that makes them feel like all the preparations have been made for the big journey. Big specs allow managers and executives who aren't fully engaged to pretend to themselves that they are.

The bottom line is that sizable bodies of law, process definitions and specs are remarkably dangerous things that require constant expert vigilance or they turn on you. The most dangerous types are the ones where parts are relevant and parts aren't. If you must use specs use short, focused collaborative things with a "use by" date much like you find on a carton of milk.