Making car insurance affordable

Motor insurance prices have been in the news recently, as the cost of legally required third party insurance has been rising recently. The claim made by the industry is that injury claims are the biggest cause.

It seems to me that there's a pair of simple fixes, which could be funded by a further tax on motor insurance.

First, you cannot claim for injury after an accident unless the accident was reported to the police within 24 hours of the accident; if you are incapacitated by the accident, this time is extended until 24 hours after you become medically capable of reporting the accident. This ties into the requirement to report injury accidents to the police that already exists (Road Traffic Act section 170), and just has the injured party also required to report to the police if they might choose to claim later. In theory, therefore, this is no burden on the authorities, as they are dealing with these reports anyway.

Additionally, an injury claim is only valid if two things apply:

1. You make arrangements to see an NHS doctor within 14 days of the accident - being taken to hospital by emergency ambulance counts here, as does making an appointment to see your GP.
   
2. An NHS doctor, at risk of losing their licence to practice if found to be lying, agrees that your injury is such that compensation is appropriate.
   

In other words, make it cheap to dismiss injury claims that aren't backed by medical evidence. Put the onus on claimants to seek medical advice - if you really think you're injured, you should be seeing a GP anyway, and we should have mechanisms in place to deal with you if you're abusing NHS services (a topic for another rant).

On the cost of regulations

I've been pointed at the Telegraph article on Steve Hilton's advice to the UK government, and one thing stands out in the article; Mr Hilton is able to count the cost of regulation, but not the benefits.

It's trivially obvious that (to take one of Mr Hilton's examples) consumer rights laws cost some businesses money; what's not discussed is the benefits of those laws, and the cost to society of not having them. Let me lead you through an example, using an expensive consumer product that many people have: a television.

You can buy televisions at many different prices, each with different features; just looking at 24" screens, I can find a cheap TV at £129, or I can spend over £1,000 on a similar looking set that's the same physical size. It's when I start to look at the differences between the sets that the sheer diversity of product becomes clear; my cheap set has one HDMI input, and a DVB-T tuner. It must be powered from a 230V nominal 50Hz AC source (e.g. household mains). My expensive set has multiple HDMI inputs, a DVB-T2 tuner as well as the DVB-T tuner, the ability to be powered directly from a car "cigarette lighter" socket (e.g. for in-caravan use) as well as from AC between 75V and 250V nominal, at frequencies between 50Hz and 400Hz nominal (making it suitable for powering from a typical luxury yacht power socket). It has the ability to record TV programmes to an attached USB HDD, and to play them back later; generally, it is of much higher specification than the cheap set.

So far, this sounds reasonable; the expensive set is a much more desirable piece of equipment. Yes, I'd have to pay more for it, but I'll get what I'm paying for. Now imagine removing consumer rights laws - let's take the law that says that goods must be fit for the purpose they are sold for. Without that law, a dishonest trader could buy the £129 TV, put appropriate connectors on the case, and sell the TV for (say) £800. They'd make a hefty profit on every set they've sold, and because consumer rights laws don't exist, nothing stops them conning a few customers, changing their trading name (so all the noise about how crooked they are doesn't impact sales), and continuing to rip people off.

Who gains in this situation, and who loses? Obviously, the dishonest trader gains. The manufacturer of the cheap TV set gains. Consumers who get ripped off lose. Less obviously, honest traders lose out; because I can't be confident that a set is genuinely what it's claimed to be, I am less likely to buy an expensive set that does everything I want, preferring to buy a cheaper set, and easier-to-verify adapters to get the added functionality.

Worse, if you say that I should rely on well-written contracts to protect me, you get into a situation where every purchase I make is slowed down, as I get the retailer to read, analyse, and eventually agree to the contract terms I insist on to make the sale. The costs to all retailers and consumers of having to deal with individual contracts, each with their own quirks are high; the benefit of consumer rights laws is that we have a baseline that the retailer cannot attempt to wriggle out of that I, as a consumer, am happy to accept. Businesses thus only need spend the costs of understanding the laws once; consumers accept that they can trust businesses, and rely on the law protecting them from the few bad apples. Neither side pays day-in, day-out for the costs of protecting themselves against the rogues in the market - instead, the legal apparatus puts as much of that cost as possible on the rogues. Further, the nature of regulation means that the net cost to legitimate businesses of consumer protection is lower than it would be if each transaction attempted to include the terms required in an individual contract.

In short, even regulations that cost money in the short term don't necessarily cost money in the long run; often, the regulations exist so that honest businesses can survive in the market, even in the presence of crooks. The trouble is that the cost of regulation is obvious up-front; the benefits are not only sometimes taken for granted, but often are spread across all of society.

On Agile, TDD, and other Software Engineering processes

I've been looking around the job market recently, and one thing that's become much more visible since I last did so is the requirement to have experience in some form of "Agile" software engineering process. While I'm not going to argue that the requirement is pointless, I do wonder how much of it is from companies who don't understand what they really want.

To understand where I'm coming from, you must first understand what an engineering process actually is. As a competent engineer, you develop patterns of work that help you produce good results every time. An engineering process is what you have when you look at a pattern of work, and write it down with explanations of why you do something. For example, test-driven development (TDD) is based on the observation that, when working with a pre-existing system, the safest way to improve things is to write tests for the functionality that you want. As long as those tests keep passing, you know the system works; as soon as they fail, you know that you've broken something important. TDD takes that further - you always write tests first for everything, even new features. You know that the new tests will fail, and you write just enough code to get the new tests passing; because you've got full test coverage, you can safely engage in quite major rework of the code, knowing that the test suite will alert you to bugs.

Another technique is pair programming. This relies on the observation that it's easier to spot other people making mistakes than it is to stop yourself making similar mistakes. So, put two programmers at one computer; have one of them write code, the other chiming in with observations and questions. Swap roles frequently, so that neither programmer gets bored.

The commonality here is that a good engineer will use whichever process is appropriate for the work they're doing; if I'm enhancing an existing feature, I will do TDD, as I can't risk breaking the existing feature, and it's easier to produce a better feature rather than a mudball of related features if I'm having to think about how it will be used as I write a test case. Similarly, if I'm deep in a complicated problem, I'll pair-program with another programmer who's as competent as I am; they force me to explain things that I think are obvious, and, as it turns out, sometimes what I've assumed is obvious is not only not obvious, but is also key to solving the problem.

It should at this point be obvious why I think that asking for experience of Agile processes isn't necessarily going to get companies what they're after. An Agile process isn't in itself helpful - they provide nice shorthands for good engineering processes, but you can practice Agile processes for years without ever doing a decent bit of engineering. For example, if you're doing TDD, you can write useless test cases, or write code that does a little bit more than the area the test case is supposed to cover. Before you know it, you're claiming to do TDD, but you're actually back in big ball of mud disaster programming territory.

Similarly, pair programming works because the members of the pair are of similar levels of competence - if you pair up with programmers who are considerably worse than you, you don't benefit from it. However, it's possible to do mentoring (pair a good programmer and a bad one together, so that the bad one can learn from the good one), and call it pair programming; from the outside, they look the same.

Practically, you don't normally want to stick with one Agile process slavishly; the core principles underlying all Agile processes are good (short release cycles, don't try and predict when you can adapt during the development process, don't waste time on something you might never need), but which detailed process is best depends strongly on what you're doing today. A good engineer knows enough to insist on pair programming when they're in a complicated problem, TDD when they're trying not to break an existing feature, Scrum-style sprints when appropriate, whatever parts of Agile will improve things today. A bad engineer will do TDD badly, so that it doesn't show gains, will use Scrum-style sprints to avoid facing up to the hard problems, pair programming as an excuse to goof off, and will generally "have experience in Agile processes", yet not show any gain from them.

What employers should really be looking for is good, adaptable engineers; these people will adjust to whatever process you have in place, will look to change it where it doesn't work, and won't hide behind buzzwords. Asking for "Agile processes" is no longer a way to catch engineers who keep up with the profession - it's now a way of catching people who know what the buzzwords are.

Having said that, I don't know what today's version of "Agile processes" should be; you need something that's new on the scene, that good engineers will be exposing themselves to and learning about, and that isn't yet well-known enough to encourage bad engineers to try and buzzword bingo their way past the HR stage.

Economics of the telecoms industry

I seem to be in a ranty mood at the moment. Today's rant, however, is not negative - it's an education attempt. In particular, I've dealt with one person too many who doesn't seem to understand how the telecoms industry works in an economic sense, and thus why the price they pay their ISP for a home connection isn't comparable to the price a business pays for "similar" connectivity. On the way, I hope to convince people that different ISPs using the same wholesale suppliers can nonetheless offer radically different levels of service.

To begin with, a quick guide to important terminology:

Capex:

Capex (short for capital expenditure) is the money you have to spend up-front to buy equipment that you'll continue to use. For example, £20,000 on a new car is capex.

Opex:

Opex (short for operational expenditure) is the money you have to spend to keep something going. Using the car as an example again, your insurance costs are opex, as is your fuel costs

Time value of money:

Time value of money is a useful tool for making capex and opex comparable. The normal way to use it is to calculate the present value of your opex cashflow; this gives you the amount of money you'd need up front to do everything from capital, without supplying future cash for opex (or alternatively without needing to allow for opex into your pricing scheme).

Cost of money:

Cost of money is another tool for making opex and capex comparable; whereas time value of money converts opex to capex, cost of money converts capex to opex, by working out how much interest you could have earned (safely) if you didn't spend the money now.

So, with this in place, how does the telecoms industry stack up economically? Well, firstly, there are three activities a telco engages in:

1. Building and owning a telecoms network, whether a small office-sized one, or a big nationwide network.
2. Buying access to other telco's networks.
3. Selling access to their own network.

Of these, the first is dominated by capex; depending on where you need to dig, and who you ask to do the digging, the cost of digging up the roads so that you can run your cables underneath them runs at anything from £20 per metre for some rural areas where no-one's bothered if your trenches aren't neatly filled in afterwards, to nearly £2,000 per metre for parts of London. In comparison, the remaining costs of running cable are cheap - ducting (so that you can run new cable later, or replace cables that fail) is around £3 per metre, expensive optical fibre is around £0.50 per metre (for 4-core fibre, enough to run two or four connections), while traditional phone cable is a mere £0.14 per metre. Even the coaxial cable used for cable TV and broadband is £0.32 per metre.

Once you've got your cables in the ground, you need to put things on the end of them to make them do good things. Using Hardware.com's prices on Cisco gear, and looking at silly kit (plugging everyone into a Cisco 7600 router, and letting it sort things out), you can get gigabit optical ports at aorund £1,000/port for 40km reach, including the cost of 4x10 gigabit backhaul ports from the router to the rest of your network.

Note that all of this is capex; given that your central switching points (phone exchanges, for example) are usually kilometres away from the average customer, you can see that the cost of setting up your network is almost all in building the cabling out in the first place; high quality fibre everywhere can be done retail for £4,000 per kilometre needed (complete with ducting), while your digging works cost you a huge amount more; even at £20 per metre, you're looking at £20,000 per kilometre. The cost of hardware to drive your link falls into the noise.

So, onto the opex of your network. You'll obviously need people to do things like physically move connections around; but most of your ongoing cost is power consumption. Again, this isn't necessarily huge; Cisco offer routers at 50W per port for 10 gigabit use, or 1.2kWh per day. At current retail prices, you'd be hard pressed to spend more than 50p/day on electricity to run the Cisco router, even allowing for needed air conditioning. Reframing that number differently, assuming that the typical customer needs £10/month of human attention, a 10 gigabit link has opex costs of around £40/month, including the 10 gig to other parts of the country.

When you compare this to the capex costs of building your network, you can quickly see that the basis of the telecoms business is raising huge sums of capital, spending them on building a network, then hoping to make enough money selling access to that network that you can pay off your capex, and spend a while raking in the profits before you have to go round the upgrade loop again; your opex costs are noise compared to the money you've had to spend on capex; assuming your network survives ten years, your opex is going to be under £5,000 per port, while your capex for a typical port is going to be over £25,000. Given normal inputs to a time value of money calculation, you can work out that a network has to survive 20 years without change before your opex becomes significant.

So, how do you make money on this? Answer: you sell connections to people; you start by charging some fixed quantity per user, to cover the bare minimum of opex and ensure that no matter how the customer uses the connection, you don't lose money on opex. Then, you add a charge for usage; there are three basic models:

1. Pay as you use of a high capacity link.
2. Pay per unit available capacity.
3. Percentile-based charging of a high capacity link.

The first is the familiar charge per second for phone calls; in this model, adapted for data connections, I pay you per byte transferred. You set the price per byte as high as you think I'll pay, so that you can pay off your capex, make a profit, and prepare for the next round of capex on network upgrades. You may also offer a variable price for usage (as my ISP, Andrews & Arnold do), in order to encourage users to shift heavy use to times when it doesn't affect your network as much. This is also where peak and off-peak phone charges came from; if you use the phone at a time when the existing network is near capacity, the telco charged you more in order to encourage you to shift as much usage as possible to off-peak, where there was lots of spare capacity, and hence allow the telco to delay upgrades.

The second is also simple. I pay you for a link with a given communications capacity, and I get that capacity whenever I use it; paying for unlimited phone calls is an example, as is an unlimited Internet connection. In this model, the telco is playing a complex game; if they make the price for the capacity too low, people will use enough capacity on the "unlimited" link that you have to bring forwards a high-capex network upgrade. If you set it too high, people will go to your competitors; a median position, used especially by consumer telcos, is to offer "unlimited with fair use", where you will be asked to reduce your usage or disconnect if you use enough that a network upgrade is needed to cope with you. This position can cause a lot of grief; people don't like to be told that, actually, this good deal for their usage level isn't for them, and that they're "excessive" users.

The third option (percentile billing) is the most common option used in telco to telco links. In a percentile billing world, there is a high capacity link that neither end expects to see fully utilised. Instead, the current utilisation is measured repeatedly (e.g. once per second). The highest measurements are ignored, leaving the percentile behind. Payment is then made based on the peak utilization in the percentile. A very common version of this is monthly 95th percentile; as used by ISPs, you measure once every second. You sort your month's measurements, and discard the highest 5% (e.g. in September, a month with 30 days, you have 2,592,000 seconds; you discard your highest 129,600 readings to get your 95th percentile). You then charge for the highest remaining measurement. For a simplified example; imagine that I measured a day's usage, and charged you 75th percentile. In February, you used 5 units a day for the first week, 1 unit a day for the next 20 days, then 50 units on the last day. 75th percentile of 28 periods involves discarding the highest 7 measurements, so I discard the 50, and 4 of the 5s, to get a measurement of 5 units peak use. I thus charge you for 5 units/day for the entire month. Had you been able to keep the last day at 1 unit, your bill would have fallen to just 1 unit/day; you can thus see how percentile billing avoids charging for rare peaks, but doesn't let a user get away with lots of heavy use cheaply.

I hope this has piqued some interest; as you can see, running a telco, especially at consumer prices, is much more akin to running a mortgages bank than a shop.

A dangerous "benefits trap"

I'm feeling compelled to write this post, because I don't see any evidence that the current Chancellor understands this trap, and I see otherwise intelligent friends not understanding just why this is a dangerous trap for a government to fall into; often, they're letting themselves be blinded by an ideological view.

The trap in question is one where increasing my taxable income decreases my net income; there are two ways for this to happen. The first is obvious - if the tax rate applicable (once you combine income tax, national insurance, and any other taxes paid on income) is above 100%, increasing your pay decreases your net income. The second is more subtle; if you are paid income-linked benefits, and the increase in net pay is offset by a greater decrease in your income-linked benefits, you lose out.

Why is this so bad? There are two reasons:

1. You set things up such that I could pay more tax, but I'll be worse off than if I pay less tax. This results in things like someone refusing a pay rise that takes them into higher-rate tax, until it's enough to make up for the loss of child benefit; the government is thus losing out on tax revenue, and paying out in benefits.
2. You encourage people to depend on benefits rather than earned income, because they're better off that way - this is bad enough when people are depending on benefits because they value their free time above their possible earnings, but becomes utterly crazy when they're doing it because they could get off benefits, but then they'd work as hard for less money in the bank.

I have set up an example spreadsheet on Google Documents to illustrate this. My hypothetical benefit is £1,000/month (housing costs, say), paid to people who earn £12,000 per annum or less. To set up the trap, we've excluded people who earn £24,000 per annum from claiming the benefit at all, and we've decided that you'll lose benefit linearly as you earn more (e.g. people on £18,000pa get £500/month benefit). I've also simplified taxation - instead of multiple taxes on income, I've got a single rate, and a personal allowance. We could add higher rate tax, and more personal taxes, but it doesn't seem worthwhile for a simple example.

You will notice that in my simple example, anyone who earns between £12,000 and £28,000/year is worse off than someone earning less than them. A rational actor will handle this by refusing to accept any job where they're paid in that range; the result is that (for example), instead of taking a job at £24,000, and paying a net £354.17/month in tax, someone sane will take a job at £12,000, and receive a net £895.83/month in benefits after tax is allowed for. It's obvious how this is bad for the government.

It's also not all doom-and-gloom; in this case, by increasing the upper threshold for £24,000 a year to £28,000 a year, people earning between £12k and £28k simply don't take home more; increase the upper benefit threshold a bit further (say to £30k), and although you don't take home much more as you increase your pay, you do take home more money, and thus escape the trap. You can also escape the trap by limiting benefits; this has other, deeper, social implications, as it can result in the benefit not helping the people it's supposed to assist.

So, how do governments end up in this trap accidentally? The usual route is to link the level of a benefit to something different to the thresholds for being permitted to claim the benefit; for example, in the example, I could have tied the benefit level to rents in London. When it started, I was paying £300/month maximum benefit; at that point, there is no trap. As rents rise, I don't review my thresholds, nor do I limit the benefit level; once rents exceed a certain threshold (around £750/month in my example), the trap appears. Capping the benefit just forces people out of an area completely, and creates "ghettos" of poor people kept out of the way of the rich, making it easier for the genuinely rich to be ignorant of what it's like living in a world where £10,000 isn't just the cost of a good night out, but is a sigificant sum of money.

Rant: On asking questions of your engineers

So, this is a pure and simple rant. Feel free to ignore it if you prefer positive thoughts.

When you are asking me a question about something, and you have a definite idea of how you expect me to answer, ask me a specific question that will elicit the answer you want. Don't ask "how well does it perform?" when what you want to know is "how many packets per second can it push?" or "how many videos can it play at once?".

If you can't work out how to phrase the question in a way that makes the type of answer you want obvious, be prepared to have to go back and forth; I'm a software engineer, not a telepath. When I respond to your question with a question of my own, it's because I'm not clear on what you want to know; I'm not trying to shove you away.

Don't get upset when I answer a question with an apparently evasive answer like "well, it's like this if you're thinking of UK Freeview, but like this if you're thinking of New Zealand Freeview, and like this if you're thinking of US cable". I'm not aiming to be deliberately irritating - I want to give you the most accurate answer I can, so that you can avoid accidentally misleading people.

I will lapse into jargon - if you understand it, it's clear as day. If you don't, say so, tell me which bits of jargon are confusing you, and I will try and explain it better. Again, I'm not trying to confuse, I'm trying to help.

When you ask me a question, give me context; don't just ask the question you think you want answered, but include details of why you want it answered. Sometimes, I'll come up with a solution that doesn't need an answer to the question you thought of; sometimes I'll find a way to give you an answer that isn't what you wanted, but that solves your problem perfectly.

Make it clear when you want a detailed answer, and when you want a high level overview; "Can we do this?" is likely to get a "Yes, but there are these problems you need to be aware of when you try and do it" or a "No, but if we did this instead, you'd get a similar result" - I expect you to know enough about why you want to do this to know if my caveats or suggestions are helpful. "I'm filling in a checklist for a bid - can I tick this box?" will get you a "Yes", a "yes, but you have to understand it this way", a "no, but if you pretended they meant this instead you could", or a plain, "no, you can't".

Finally, remember that I'm a person, too, and that means I want to help you if I can - don't cut me off or get annoyed when I offer an answer that isn't what you want; instead, work with me to get yourself an answer that's possible, and that you can live with.