Our legal code is almost entirely like an entire operating system written in undocumented Perl.
- There are no hints as to what any part of it is supposed to do and it is written in a language that to most people looks like line noise.
- Every significant patch is applied by adding an additional Perl module that overrides an existing method in an existing module, replacing all of the code in that method with a complete new copy of the method that is almost identical to the old one but adds or removes a backslash in a single regular expression.
- The entire core logic was written in a crunch session by a bunch of geeks locked in a room together and forced to design it by committee.
- The application was a rewrite of another application that never really worked well in the first place.
- Every function name is chosen explicitly to provoke an emotional response in the developer, e.g. thisFunctionSucks() or callMeNow().
Although that was somewhat tongue-in-cheek, there was a certain grain of truth to it.
It seems that I’m not the only one to think this – and indeed, someone has taken the idea even further by applying systems design principles to the new health care reform legislation that the US Congress is working on at the moment.
Bruce F. Webster writes:
On the occasions where I have reviewed the actual text of major legislation, I have been struck by the parallels between legislation and software, particularly in terms of the pitfalls and issues with architecture, design, implementation, testing, and deployment. Some of the tradeoffs are even the same, such as trading off the risk of “analysis paralysis” (never moving beyond the research and analysis phase) and the risks of unintended consequences from rushing ill-formed software into production. Yet another similarity is that both software and legislation tend to leverage off of, interact with, call upon, extend, and/or replace existing software and legislation. Finally, the more complex a given system or piece of legislation is, the less likely that it will achieve the original intent.
He then goes on to talk about some “design flaws” in HR 3200 – otherwise known as the “America’s Affordable Health Choices Act of 2009.” (Brings to mind point #5 from the “Legal System as a Perl OS” quote from above, doesn’t it?)
Bruce then goes on make a point which is basically the same as point #2 in the “Legal System as a Perl OS” quote above:
Much of HR 3200 makes piecemeal modifications to existing legislation, often with little explanation as to intent and consequences.
Or to put it another way, entire sections of HR 3200 do nothing other than override some existing legislation in some incredibly small way, which will (presumably?) have huge (and in all likelihood, unintended and unforeseen) effects – much like how adding or removing a single backslash from a regular expression can have huge (and often unintended and unforeseen) effects on its pattern-matching behavior.
Bruce’s entire article (it’s the first of a 3-part series – as I write this, only parts 1 and 2 are done) is well worth reading – and in fact I highly recommend it, even for non-programmers.
Of course, if you ask me, I really think all legislators should be required to take a programming course or two – because, as I’ve said before (in my “A Programmer’s Perspective on Politics” article), laws are effectively the “operating system” of our society… and right now, the people writing our society’s “operating system” don’t seem to be particularly good programmers!!
