Justin du Coeur (jducoeur) wrote,
Justin du Coeur

Paradigms of Imperatives

Interesting. As I was randomly musing this morning, it occurred to me that my strong and slightly idiosyncratic opinions about how one writes Good Law don't exist in a vacuum. Instead, they're very closely (and probably not accidentally) related to how I think about Programming.

Thinking about that, I shouldn't really be surprised. The two fields are conceptually similar: both are all about stating how things should work, as precisely and accurately as possible. They're not identical, to be sure: programming is about describing *how* to do things, whereas law is more about describing *what* you should do. But the mental pathways are simillar -- in particular, writing law is rather similar to the design process for code.

The resulting relationship seems to be largely at the aesthetic level. I have a strong intuitive concept of "good law", which is very similar to my concept of "good code". Some of the characteristics that they share in common:
  • Good law, like good code, is highly orthogonal -- a well-written law concerns itself with a single problem space insofar as possible, avoiding contamination by unrelated matters.

  • Good law, like good code, is highly transparent -- it should express both its purpose and its means clearly, without trying to be excessively deep or clever at the cost of being confusing.

  • Good law, like good code, is highly modular -- it should be made up of small, focused pieces that each do one thing precisely and well.

  • A sub-body of law, like that of code, should be cohesive -- the pieces should work together sensibly. This is best expressed by its opposite: both do badly when people hack special cases into them, without properly considering how those hacks work in the larger context. Both tend to do best when new ideas are subtly worked into the entire body, rather than added as special cases.
All of which begs an interesting question: can the lessons of the past decade of software engineering be applied to law? Does it make sense to do continuous refactoring of laws, the way a good engineer does continuous refactoring of code? Is there an "object-oriented" paradigm of law, that permits good modularization? Should we think in terms of "interfaces" between laws and how they interrelate, trying to define those clearly?

All of this is idle speculation at this point, of course, and I'm sure that the idea is greatly oversimplified. But there may be a kernel of truth here. Just as programming has reached the point where it requires a serious engineering discipline to be able to work with sophisticated systems, I get the impression that law has long since passed that point, and it appears that it still largely lacks that discipline. I'm not sure that there's any way to impose such a discipline on it, at least in the large scale, but there might be a set of priciples worth deriving and advocating here...

  • The O Ya omakase menu

    I've occasionally mentioned the over-the-top splurge that Kate and I did for our Dinnerversary last year, going to O Ya for their omakase tasting…

  • O Ya

    This past Friday we observed Dinnerversary -- the third anniversary of Kate's and my first officially-not-a-date. In recognition of finding cool new…

  • Masa: Followup

    About a month ago, I wrote a review of Masa Restaurant. The summary is that it was excellent food, dinged only by service that was, to put it…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded