Unit tests for laws
You read a lot about how vague many laws are. That's a real problem, because it makes people afraid to do legal things for fear of breaking the law. It also puts far too much power in the hands of prosecutors, because they can probably find some way to pin anything on anybody. Legislators aren't induced to think about these things when they draw up their laws, which is how vague laws get passed. Then later it's difficult to infer the original intent of the legislators, which magnifies the problem.
This exact situation happens in software. Lots of times we end up writing tricky code. Sometimes it needs to be tricky, sometimes it's because we're too lazy to write it neatly. A good thing to do with tricky code is to write more code to test the feature code. The test code sets up a particular situation, executes the feature code, and then verifies that the outcome was as expected. Verifying the outcome involves not just testing successes but also making sure that the code fails appropriately and gracefully when it it applied incorrectly.
A key part of a code test is making sure to check the boundary conditions, the points at which something distinctive changes. For example, if you have an accounting function that does different things based on when the tax rate is more than 8%, you would test its outputs with a rate of 7.99%, 8%, and 8.01%. That way you could make sure that the difference applies to "more than 8%" rather than "at least 8%," a mistake that could have potentially significant consequences. Another way of looking at it is to say that you should test that every different clause is applied appropriately and works correctly.
The obvious benefit is that this kind of testing verifies the feature code is correct. Less obvious benefits happen over the long run. Writing test code is often more work if the feature code is poorly specified or excessively complicated. The prospect of writing a long, complicated test motivates us to look harder for a simpler solution to the original problem. Long, complicated tests can highlight silly preconditions or consequences, which provides a similar motivation. Finally, the test code itself can serve as documentation of how the feature code is intended to work. You can see that A, B, and C1 are necessary to achieve result Y, and if C1 is replaced with C2 the result is Z instead because the test says that explicitly. That's often more illuminating than trying to parse the code.
As applied to laws, my hope is that anyone who draws up a law would also describe numerous scenarios of how one applies the law. Then those considering the law could see if those examples made sense. For example, in a law covering shipments of alcohol, one might have one scenario regarding shipment of wine in-state vs. inter-state, or beer sent by plane rather than by truck. They would also
Unlike software tests, which a computer checks, they would also need to make sure that the law as written actually does do what the examples say. They'd need to verify that the examples are actually useful. If someone writing a bill provides useless or inadequate examples, it'll be obvious, as legislation is a far more visible activity than writing software.
In a sense, you could argue that judicial precedent establishes a body of tests and descriptions of how a law should work. However, this takes years to happen at great cost, not just for the parties directly involved in the suit, but also for anyone who suffered from the problems with the law before the establishment of the precedent. It's like fixing a bug only after you've wiped dozens of people's hard drives.
You could also argue that this would slow down the legislative process. Well, you could argue that, but you'd be wrong, both in premise and conclusion. Slowing down the legislative process isn't necessarily a bad thing; it's not like we have too few laws. Additionally, it may add a step to the process, but it'll also cut down on debate, delays in implemepoliticsnting laws as various interest groups seek injunctions, and so forth. The net result would be a system with fewer laws, but the laws that we had would be better.
This exact situation happens in software. Lots of times we end up writing tricky code. Sometimes it needs to be tricky, sometimes it's because we're too lazy to write it neatly. A good thing to do with tricky code is to write more code to test the feature code. The test code sets up a particular situation, executes the feature code, and then verifies that the outcome was as expected. Verifying the outcome involves not just testing successes but also making sure that the code fails appropriately and gracefully when it it applied incorrectly.
A key part of a code test is making sure to check the boundary conditions, the points at which something distinctive changes. For example, if you have an accounting function that does different things based on when the tax rate is more than 8%, you would test its outputs with a rate of 7.99%, 8%, and 8.01%. That way you could make sure that the difference applies to "more than 8%" rather than "at least 8%," a mistake that could have potentially significant consequences. Another way of looking at it is to say that you should test that every different clause is applied appropriately and works correctly.
The obvious benefit is that this kind of testing verifies the feature code is correct. Less obvious benefits happen over the long run. Writing test code is often more work if the feature code is poorly specified or excessively complicated. The prospect of writing a long, complicated test motivates us to look harder for a simpler solution to the original problem. Long, complicated tests can highlight silly preconditions or consequences, which provides a similar motivation. Finally, the test code itself can serve as documentation of how the feature code is intended to work. You can see that A, B, and C1 are necessary to achieve result Y, and if C1 is replaced with C2 the result is Z instead because the test says that explicitly. That's often more illuminating than trying to parse the code.
As applied to laws, my hope is that anyone who draws up a law would also describe numerous scenarios of how one applies the law. Then those considering the law could see if those examples made sense. For example, in a law covering shipments of alcohol, one might have one scenario regarding shipment of wine in-state vs. inter-state, or beer sent by plane rather than by truck. They would also
Unlike software tests, which a computer checks, they would also need to make sure that the law as written actually does do what the examples say. They'd need to verify that the examples are actually useful. If someone writing a bill provides useless or inadequate examples, it'll be obvious, as legislation is a far more visible activity than writing software.
In a sense, you could argue that judicial precedent establishes a body of tests and descriptions of how a law should work. However, this takes years to happen at great cost, not just for the parties directly involved in the suit, but also for anyone who suffered from the problems with the law before the establishment of the precedent. It's like fixing a bug only after you've wiped dozens of people's hard drives.
You could also argue that this would slow down the legislative process. Well, you could argue that, but you'd be wrong, both in premise and conclusion. Slowing down the legislative process isn't necessarily a bad thing; it's not like we have too few laws. Additionally, it may add a step to the process, but it'll also cut down on debate, delays in implemepoliticsnting laws as various interest groups seek injunctions, and so forth. The net result would be a system with fewer laws, but the laws that we had would be better.
posted by Ketan at
10:24 AM
0 Comments
