Software engineering best practices applied to lawmaking.

(Originally suggested to a few people over email and in private discussions, February 2011 and onwards. Edited for readability.)

This is US centric, but could apply elsewhere.

As far as I can tell, the process by which laws are created and changed is very clumsy. At least one congressperson has said during an interview that nobody reads the text of bills. A glance at C-SPAN on any given day shows a lot of empty seats and general inattentiveness. Most bills pass or fail with a lot of uncast votes. I don't know it for a fact, but I'm under the impression that the situation is similar at all levels of government.

In a related problem, the lawmaking process at all levels from local to county to state to federal is not transparent in a way that would meet the expectations of 21st century, internet-connected citizens. The direct involvement assumed by the founders is less feasible today than in years long past, in part because of the ever-increasing ratio of population to representation. Washington himself argued that one representative per 40,000 citizens was inadequate, but as of now the number is somewhere beyond 650,000! Simple population growth over 200+ years made keeping near-original levels of representation impossible.

(650,000 current / 30,000 Washington's proposed) * 435 current reps = 9,425 reps if we scaled his proposal up to our population size

How big a capitol building would it take to seat a congress of ten thousand? How would that many people coordinate to get anything done? It's not going to happen for these and other reasons. So since the brute force approach of throwing more representatives at the problem doesn't scale up and hasn't for a very long time, we should be thinking about how to achieve the desired result by other means.

There have been noteworthy attempts at transparency in lawmaking over the past few years. One that comes to mind is New Zealand's move to put bills online where they can be commented on. The lawmaking body isn't legally bound to take the comments into consideration, but presumably that happens at least some small percentage of the time. More recently, Iceland has decided to write a new constitution in part by "crowdsourcing" it, using twitter, facebook and other modern ways to connect with the citizens. These are good starts, but we can do better.

Version control and peer review are at the core of all good software projects, and any engineer at any good software company or open source project is fluent in best practices that make the lawmaking process seem stone age by comparison. But on closer inspection, the lawmaking process and that of making changes to a large codebase in a software project are strikingly similar and most of the best practices and even tools could be applied directly or with very little modification.

The peer review process and code ownership bears some vague resemblance to positions in government, but a group of programmers with a revision control system aren't a democracy, republic, dictatorship, or anything else I can think of. There's a hierarchy of people who have the power to approve or reject local changes up to broad, sweeping changes. Let's pretend we're working on a code base with a heirarchy that looks like this.

/california_state_code
/california_state_code/agriculture
/california_state_code/agriculture/irrigation
/california_state_code/transportation

If your day to day business is working on irrigation and you're declared to be its owner/maintainer/expert, you can make changes to it very easily. The only requirement is that a second pair of eyes, anyone's eyes, looked it over. The reviewer only needs to know about the state lawmaking process and have a conscience, not be an expert in your narrow area of expertise. If there turns out to be a problem with your change later, it will be obvious that you were responsible and you'll have to defend it when it's audited.

You can submit a change for review to anywhere in the tree, but will need to get the approval of its owner since presumably that person knows more about it than you. If you want to make a change to agriculture beneath the level of your domain (irrigation), you need to get approval from an agriculture owner before you can submit. That person is typically is an owner of the whole domain of agriculture, including irrigation, and can make changes to irrigation without necessarily needing to consult you (though they often would since you're the expert).

Similarly, if you want to make a change to some important, widely referenced law at the top level of the state code, or make an emergency change to a badly worded law in transportation that has dangerous consequences for irrigation when the usual owners of transportation have run off to play golf in Vegas or something, you'll need to contact an owner of the whole state code. Since nobody can possibly be an expert at every project in a big code base or article in a body of law, the root ownership is reserved for people who can be trusted to make rational decisions and important judgment calls when they don't always have as much background as they'd like. Basically, level-headed people who can spot bad ideas and offer better alternatives in a wide variety of contexts.

A lot of these concepts map roughly to positions in our government like house committees and sub-committees and their chairs, but the critical thing about the software development model is that people tend to operate in their domain of expertise yet are perfectly able when necessary to make changes to anything, anywhere, when necessary, just so long as the trusted authority gets a chance to read it first and sign off on it. Owners of any part of the code base aren't usually flooded with requests to change things because most of the time people just stick to their own stuff. It's brilliantly fluid and was developed out of necessity. When applied to congress, we would almost certainly begin with the current model of requiring a majority of members to approve changes rather than exactly duplicate the software development model, since that would be a very disruptive change. I anticipate we'd experiment with the formula someday though since it's much more efficient. Problem is you need to put a lot of trust in everyone for it to work, and until the benefits of transparency kicked in and lawmakers were forced to become more trustworthy over time, our current majority system is a safer bet.

The tools of the trade that make the above-described peer review and check-in process possible allow people to work from anywhere they have an internet connection, even if it's only sporadically available. Review tools exist that highlight (literally and metaphorically) the differences between the existing version of a piece of code (or law, in our case) and the proposed new version and allow comments to be made inline, in context. There's an audit trail of who changed what and who approved it, what the discussion was at every step, what had to be changed in the proposal between when it was first submitted for review and when it was deemed acceptable by the reviewers. Approvals are explicit and unmistakable. Changes found to be harmful can be rolled back in their entirety by means of an identical review and approval process.

Congresspeople could work from home, their offices in the home state or DC, from the floor of the house, wherever, and the physical presence loophole sometimes used to sneak bills in during periods of low attendance would be entirely removed. They could meet and conspire in smoke-filled rooms all they wanted, or discuss things off the record over a beer or two as much as needed, but in the end the actual change would still have to be approved by folks who may or may not have been present on a given day. As an added bonus, once physical presence is divorced from the process, the size of the group doesn't have to be kept as small if we ever felt like experimenting with it (and maybe we wouldn't have to). Would we be better served by a congress of 435 or 10,000 or something in between? Try a few things and see.

This all applies to all levels of government. The transparency comes in when the review process is opened to the public. It would unfortunately be impossible to allow all 300 million Americans to propose changes to laws or make comments during reviews; the noise would be unbearable. At least they would be able to watch the legislative process as it happened, which is a very important step.

I don't expect that every citizen would choose to be any more involved than they already are, but on average everything would probably be read by at least someone, which is a step in the right direction. Not everyone who uses open source software is involved in the development process, but the users all benefit from the added participation of even just a few volunteers.