Sunday, February 8, 2009

Ideal Lawmaking

Laws bear an uncanny resemblance to computer code. If this analogy is an accurate one, then it should be theoretically possible to simulate the effects of new laws before they are enacted. Lawmakers could then argue about the “requirements” of the “software” instead of wasting time in “programming” and “code review” (the equivalent of a software development team’s programmers could handle those chores).

The simulation (in a “development environment”) would be run and its results analyzed by “quality assurance (QA) engineers” for conformance to the requirements. Deviations from requirements (“bugs” in the “software”) would be corrected by the “programmers.” When the output of the simulation met the requirements, then the actual law would be enacted in a “test environment” that was representative of the larger conditions it would apply to when finally enacted. The “QA engineers” would evaluate the results and recommend any “bug fixes” to the “programmers” as well as necessary modifications to the predictive software (thus improving the accuracy of future simulations). When the law passed its tests and reality matched the simulations, then the law would be fully enacted. This process seems to be a reasonable approach to lawmaking, which ideally should achieve predictable results.

Reality is, unfortunately, much different. In the United States, legislators, like business analysts in software development, do collect the equivalent of requirements from “shareholders” – their constituents – but then they turn directly to crafting the laws, the equivalent of programming (admittedly with some help by staff lawyers), even though not all of them are even familiar with the language. Experts serve the role of both stakeholder representatives (in the requirements gathering phase) and predictive software (providing opinions about the effects of the laws, which is the equivalent of a simulation’s output). Laws are then enacted, like releasing software without testing it. When problems are found in the real world – as they often are – the legal system (judges and lawyers) performs the role of quality assurance. Precedent and court opinions act as modified user documentation in the software analogy; and if this isn’t sufficient to address the problems, lawmakers may alter the law like programmers making bug fixes, or create new laws if necessary.

When our government was set up, populations were small and relatively isolated. Legislators had direct experience with the results of laws in environments where failure had limited impact. Crafting “requirements documents” could be done by almost anyone, and the legal implementation was short and understandable by most people. Now we live in a large, complex, interconnected system, whose domestic population is approaching 80 times larger than at our founding, and whose impact on the entire world is arguably greater than any other nation.

It is possible that modeling of human behavior and the physical systems we interact with may not be up to the task of providing a reasonably accurate simulation of the potential impact of any but the simplest new law. Even if computers can handle the grunt work of generating predictions, the theoretical and empirical underpinnings of a model may not adequately exist. With so many people’s lives at stake, shouldn’t we at least try, achieving the best approximations possible (and improving them along the way)?

No comments: