“If I were writing laws such that I wanted everybody to agree on how to interpret them, I would use the software development life cycle: First, have lawmakers (analogous to “developers”) write drafts of the laws. Then a second group (the “test case writers”) would try to come up with situations that would be interpreted ambiguously under the law. Then a third group, the “testers”, would read the proposed law, read the test case situations, and try to determine how the law should be applied to those cases, without communicating with the law writers, the test case writers, or each other. If there’s too much disagreement in the third group on how the law should be applied, then it’s too vague to be a proper law. The only laws which made it through this process would be ones such that when they were finally passed, most citizens (the “users”) could agree on how to interpret them, in cases sufficiently similar to the ones the test case writers could come up with.”
The whole article is worth a read, don’t let the computer programmer jargon in the quote scare you. Some of the comments are quite insightful too and worth a read. I like the idea of the double blind test for laws that Haselton describes but as one of the comments points out, it is impossible to predict how a law will be read in the future, which is why we have courts and lawyers in the first place. But I think looking at the Software Development Life Cycle [wikipedia.org] is helpful here too; it is impossible to fully predict how the users of your software (or any other product) will use the product or what changes will be desired in the future. The SDLC does not end when the software goes into production, if the software works there will no doubt be updates, if it does not work there will be updates or new software or the software will die. Maybe we should not just use the double blind test when a law is written, maybe when the courts need to step in the law itself should be subjected to possible change and modified so that it meets up-to-date test cases.