Shotgun Debugging, Constitutional Law, and the Argument from Elegance

[maradydd]

As some of you know, I have a rather lengthy post in the works about the history of challenges to initiative amendments in California -- that is, constitutional amendments which are proposed by a petition of the people and decided by popular vote. It's 1500 words and counting, and will probably hit 3000 by the time it's done, but I wanted to make sure that folks who want to understand the precedents coming into play with Strauss v. Horton, the ACLU's challenge to Prop 8, have a good resource for that. However, the following came up on theinated's journal, deep in a comment thread, and I think it's important enough to bring up here.

But first I'm going to talk about software engineering. I promise, it's relevant.

In the code-slinging trade, there's a concept called "shotgun debugging" which makes every seasoned engineer foam at the mouth. The Jargon File defines it as "the making of relatively undirected changes to software in the hope that a bug will be perturbed out of existence". "Relatively" is loosely applied here; typically the code you tweak has something to do with the problem -- if the problem is in your user interface, twiddling with interprocess communication usually isn't going to help -- but you're not sure where the exact problem is, so you poke at a bunch of different places and pray you got it right.

Don't do this. It's practically guaranteed that you will make things worse, most likely by creating new bugs that are subtler, more obscure, and will bite you in the ass for years to come. But keep the concept of shotgun debugging in mind, because we're going to talk about it again shortly.

Elsewhere, lather2002 wrote:

There are ways for same sex couples to have rights that allow them basically the same rights as "Married Couples".

In principle, lather2002 is correct. However, the institution of marriage is deeply embedded in the principles of English common law upon which our legal system is founded, and altering those principles to cover civil unions would involve a massive rewriting of the law which amounts to shotgun debugging of the very worst sort.

Looking only at statutes, we can easily find dozens of areas in which marriage plays a role: tax law, estate/inheritance law, family law, laws having to do with visitation rights (both for hospital patients and for prisoners), property law, insurance law, torts (e.g., wrongful death suits), and so on. Attempting to shotgun-debug the California code in an attempt to create parity between marriages and domestic partnerships is a fool's errand; there are just too many places where marriage is closely intertwined with statutory law to be able to do the job right. California tried to do it all in one go by providing that domestic partners are to have all the rights and responsibilities afforded to married partners, but the very bill that established this also carved out several exceptions. Establishing a domestic partnership requires different prerequisites -- among other things, the couple must live together before becoming domestic partners, which isn't required for marriage -- and it isn't possible to have a confidential domestic partnership (i.e., one that isn't a matter of public record), while it is possible to have a confidential marriage.

However, the matter gets fuzzier. In some situations, the principles of common law protect the institution of marriage in a way that isn't actually codified anywhere. A good example is the notion of privileged communication. There are certain types of communication, such as that between a lawyer and her client, a doctor and his patient, a priest and a penitent confessing to him, which are "privileged" in the sense that neither party can be compelled to disclose the contents of that communication. If a defendant admits to his lawyer that he committed the crime with which he is charged, the lawyer cannot be compelled to disclose this to a third party. Spouse-to-spouse communication is protected in exactly the same way: one spouse cannot be compelled to give evidence against the other (also known as "spousal immunity"), and in fact one spouse can prevent the other from disclosing information which was communicated privately between the two of them (also known as "marital privilege").

For what it's worth, the matter of privileged communication has a lot to do with why the right to marriage is viewed as derivative of the right to privacy -- which is expressly protected (in fact, it's inalienable) under CA constitutional law.

Some states have passed statutes which restrict privileged communication in some form; for instance, Washington state has made attorney-client privilege a one-way street from client to attorney (the client can be compelled to testify against the attorney on matters of communication that don't have to do with the client's communications). California has codified attorney-client privilege the opposite way, protecting all attorney-client communication regardless of subject, but that merely reinforces the common-law definition; it does not expand it. I can't find an example of a law which creates a new class of privileged communication. Expanding privileged communication to domestic partnerships is thus quite difficult, and privileged communication isn't the only area of common law where marriage comes into play.

Shotgun-debugging a body of statutory law is hard enough; how do you shotgun-debug hundreds of years of tradition? Under the principle of stare decisis (literally "to stand by and adhere to decisions"), which obligates judges to follow the precedents established in previous case law, you can't. Only marriage is marriage, and there is no precedent for "domestic partnership immunity"; in this respect, the court's hands are tied. Even if statutory law mandates equal treatment before the law for domestic partners, the court cannot magically create privilege where none exists. There can be no parity between marriages and domestic partnerships.

I'm going to turn back to the Jargon File, now, to address the topic of elegance: "Combining simplicity, power, and a certain ineffable grace of design." Software engineers love elegant code: it's easier to understand, easier to work with, and it's aesthetically pleasing. Linguists adhere to the principle of elegance, too: given two sets of rules which describe the exact same grammar equally well, the one with fewer rules is to be preferred, as complicated rules are difficult to apply and lead to errors.

I'm not going to pretend that law adheres to the principle of elegance -- the sheer size of the California constitution, much less the California code, is testament to that -- but in this instance, we would do well to observe it. If we wish to establish parity between same-sex and opposite-sex couples, the simplest, least confusion-causing, most elegant solution is to legalise marriage between both same-sex and opposite-sex partners.

(This is, incidentally, the fundamental flaw I see in the "then let's make everything a civil union" argument. Taking away spousal privilege is a horrible, horrible idea that would remove the protections of hundreds of years' worth of important, rights-preserving court decisions which hinge on spousal immunity or marital privilege. Please take a look at the bigger picture here; let's not cut off our noses to spite our faces.)

Comments

[mellowtigger]

A good metaphor. Keeping the same programmer frame of mind, what about "aliasing" or "overloading" the marriage function so that it accepts same-gender inputs? There'd be no new code underneath, just a different function call to the same ol' code.

[maradydd.livejournal.com]

I like to think of it as pulling up (http://www.refactoring.com/catalog/pullUpMethod.html) the marry(spouse1, spouse2) method, myself, but I'm a refactoring junkie. ;)

[lightning-rose.livejournal.com]

Operator overloading is the work of the devil!

[maradydd.livejournal.com]

This can actually be handled quite cleanly in C++ using template function overloading: declare one version of the function as template <typename T> and the other as template <typename T, typename U>. The compiler will introspect on the argument types and determine which version of the function to call.

I think I'm officially too geeky to live.

[lightning-rose.livejournal.com]

Overloading is fine for writing code, but it makes it nigh on unreadable for someone who's never seen the code before. ie: With

a = b + c;

even if you know what a, b, and c are, you have *no* idea what the code is doing.

[maradydd.livejournal.com]

Hrm. So, as a developer, I usually expect that anyone who has implemented a class that I might reasonably expect to call standard library algorithms (e.g. std::sort or std::max_element) on has implemented whatever functions or operators (e.g. operator<) I will need to be able to use those algorithms. For instance, given a class Complex which represents complex numbers, I should be able to identify the largest or smallest item in a container of Complex via a call to std::max_element or std::min_element respectively -- each of which rely on std::less, which in turn relies on operator< being overloaded (which actually means "defined") for the type Complex. If operator< isn't overloaded, code which invokes anything that ultimately relies on that operator just won't compile.

As a developer, I neither need to know nor care what's going on under the hood; this is the magic of encapsulation. (As an implementor, sometimes I'm curious how other people did it.) I merely want a promise from the implementor (e.g., in the class documentation) that necessary operators are overloaded in some meaningful way. operator++ should increment its caller sanely, e.g., incrementing a Date object whose value is February 28, 2008 should produce a Date whose value is February 29, 2008. Similarly, adding n Length and m Length should give me n+m Length, but multiplying n Length and m Length should give me n*m Area.

All that said, it's absolutely possible to overload operators in unhelpful ways. I actually agree with Elliotte Rusty Harrold (http://cafe.elharo.com/blogroll/operator-overloading/)'s argument that people who don't have a basic grasp of groups, rings and fields, and who don't understand dimensional analysis ("apples plus apples is denoted in apples, but apples times apples is denoted in units of apples squared"), really have no business overloading operators. Fortunately, dimensional analysis is easy to pick up if one has forgotten it from high school physics, and the fundamentals of abstract algebra can be picked up in half an hour.