Thursday, 27 September 2007

Fixed-term elections

Lynne Featherstone has been blogging about the fact that the prime minister currently gets to pick the election date (and notes that Gordon Brown was for fixed parliamentary terms in 1992, but not, wonder of wonders, now that he's in charge).

On the one hand, a change to fixed parliamentary terms ensures that governments can't wait until the high-water mark and call an election when they are popular. On the other hand, considering the fickleness of the media and of opinion polls, having fixed terms could lead to a situation in which a government that had been largely popular throughout most of its rein was thrown out at a low point.

This strikes me as a sampling problem. Imagine a graph with government popularity on the Y axis and time on the X axis - you'd get a wiggly, wavy line. Taking a sample every 4-5 years is a very, very imprecise way of recording how popular the government has been over time.

I propose that government is sampled more often, and that, say, 20% of constituencies go to election each year, at a neutral time of year like spring or early autumn. That way, a government's power can be continually regulated by the people. Of course, there would be no more landslide victories for one party or another, since it would take several years for the total composition of parliament to change. But would that be a bad thing?

Thursday, 20 September 2007

What This Is All About

This is a blog about how the principles of software engineering could be applied to the UK Parliament.

Software engineering is different from mere "computer programming": it is concerned with developing high-quality software, not just a "botch job" that gets by. That means making sure that things get done right throughout the development process.

Our parliament should be about creating high-quality laws. It currently isn't. That says to me that in order to improve our parliament, we need to change the rules under which it operates.


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.
There's this thing in engineering called SMART requirements. You probably don't want to follow that link. Here's a summary:

Basically, when you make a piece of software, you need to know what to make. It turns out that this is the really hard part of software engineering. By and large, design, programming, testing and rollout are all well understood fields with a bunch of best practice books and so on kicking around in order to do them well. (Design is still a bit more of an art than a science, but I think that any engineer worth his salt can do good design intuitively.)

So, gathering a client's requirements and turning them into a system design that accurately reflects the requirements is quite hard. There is no accepted universal method, and even if there was, most clients probably wouldn't know how to do their part of it. It's also where the politics of engineering come in - who's in control of what, which bits of risky development can be parcelled out to whom, and so on.

One of the tools I've seen to ensure a higher quality of requirements gathering is the notion of SMART requirements. It is effectively a combination of a tree-structured hierarchy of systems requirements with a checklist for ensuring that each node in the tree meets some basic rules. Here are the rules:

S - Specific: Specific requirements are clear, consistent, simple, and "of an appropriate level of detail".
M - Measureable: The system can be checked against measureable requirements to indicate whether the system meets the requirement or not.
A - Attainable: Attainable requirements are those which can be reached by the system.
R - Realizable: Realizable requirements are those which can feasibly be reached by the system.
T - Traceable: Traceable requirements can be associated with every onward part of the system: design, implementation and testing elements.


So how can SMART requirements be useful in politics?

In the drafting of bills of law, that's how. If every law passed had to be Specific (not wordy, concise, clear), Measureable (identifying clear measures of success), Attainable (the aim of law was possible), Realizable and Traceable (any programs instituted would be clearly identified with measures and the individual laws and parts of laws that brought them into force), we might be a lot better off.

Particularly if a second, independent body were to be responsible for identifying measures of success and feasibility. I would hope to engender a situation like this:

"Cannabis is dangerous, we want to reduce the number of people who smoke cannabis because it is a health risk. Let's try reclassifying it to a class B drug."
"Sure. Let's take note of how many people are smoking it now, and how many are suffering adverse health effects, and you can give it a go."
-> 5 years later...
"Hmm, making cannabis more illegal didn't really work. We'd better repeal that law."