Review

One of the most important ways to ensure quality in software systems is the process of review. A document, or piece of code, or test script, is not simply written by one person and accepted. It is written then reviewed, first by the author, then by a peer or superior, or more than one.

The UK Government has a system of review, too. A bill will often be published in draft form before being introduced into the law-publishing cycle. Amendments can be made here, then during the second reading, again when read in the Other house, then at the committee stage. Sounds good, doesn't it? Except that at all points, only a majority vote is required to pass amendments. When you have a system of majority government, that means that the party in power can pass whatever laws it likes. Sure, the review process will pick up on obvious and honest mistakes in the same way that the software engineering review process does, but anything really contentious will get left in. Bless the Lords, they've fought a few bills here and there, but the Lords can only delay matters.

This doesn't jive with the idea of creating high-quality laws. How often have we seen governments "toughen up" laws on crime when there is some political capital to be made from it? Or introduce laws that patently have the opposite effect to that which was intended? Partly this is a matter of defining laws well enough in the first place, but partly, it's a matter of review.

So how could one engineer a better system of review in parliament?

There are four groups of people who review things in software engineering:

1. The author. Bearing in mind that the authors are politicians, getting them to review their own stuff for the presence of "good quality" seems rather difficult. They already submit positions of intent for new laws to clarify their objectives, which are just as easy to fudge as the law itself. Let's presume, instead, that all politicians are self-interested sociopaths for the moment.

2. Peers. Laws already get reviewed in the Commons, of course, and in select committees, but neither have any real power of alteration. On the other hand, requiring a greater than majority could lead to the sort of compromise politics and horse-trading that makes a different kind of poor-quality law. One could, perhaps, require a 52% majority to pass alterations, meaning that at least a few members of the other party must co-operate. Or some interesting scheme whereby at least 5% of every opposition party in the house must agree. But again, I think that this is a flawed solution.

3. Superiors. In the political sense, I suppose that this would be the Lords. As it stands, though, the Lords is a body appointed by governments past and present. To ensure an independent eye is cast over any new law, one could constitute an entirely apolitical upper house - perhaps through sortition. If these Lords were given the powers to ensure that bills were appropriately SMART, then perhaps that would go some way to preventing spurious lawmaking.

4. Clients. Not much is reviewed by clients of a software product - tested, perhaps, but not reviewed. The only occasion in which they do get involved is if they are involved in construction of some initial documents themselves. The problem is that the clients largely lack the technical skills to review properly. One could say the same about the electorate, particularly given the (dis/mis)information fed to them by the mass media.

However, one of the biggest challenges in software engineering is giving the client what they actually need (different from what they want or what they ask for). That can only happen by understanding the clients well enough and it seems that in a political system the best way to figure out what voters need is by asking them. So perhaps we might think of having more referendums on more topics.