Risk and Denial

Our grasp of risk, unless it’s accompanied by fear, is generally unreliable. We’re equally poor at acting rationally when it comes to gambling for gain. More often than not we act in stupid denial of elementary probability theory.

For example, crowds flocked to Romford last week to buy tickets for the National Lottery. It’s the luckiest town in the UK in terms of lottery winners, and the ‘rollover’ reached a record high before this weekend’s draw. Morons.

And last week the Government’s chief medical officer issued new advice on alcohol consumption. Men may no longer drink more than women, none of us must drink more than 14 units a week (seven glasses of wine), the slight benefits of alcohol are confined to women over 55 and all of us must abstain from alcohol on several days each week. There is no level of alcohol consumption that is safe.


Denial, predictably, was immediate. A succession of red-faced and unwell-looking men and women popped up to say they’d been drinking heavily for years and it hadn’t done them harm.

Tweets to BBC News arrived thick and fast:

‘How can there be a recommended level of consumption if there’s no level that’s safe?’

‘How can we believe the Government if their advice keeps changing?’

Frankly, these reactions are as stupid and annoying as when you ask someone for an average and you get the answer ‘Well, sometimes there are as few as ten and sometimes as many as a hundred.’ There’s no excuse for mathematical innumeracy on this kind of scale.

Is there anything more infuriating and tedious than the old lady who smoked thirty a day, drank half a pint of vodka before breakfast and lived to be a hundred. We’ve all got these improbable survivors lurking somewhere in our family trees. And we all trot them out when someone tells us that smoking and drinking are bad for us.

Doesn’t anyone understand a probability curve?


It’s absolutely clear what the UK’s Chief Medical Officer is telling us. True, it might not be the final word on the matter; all scientific research is provisional. But if you can be bothered to listen or read more carefully you’ll see that the idea of a ‘safe level’ is defined as a lower than 1% risk that you will die as a result of alcohol consumption.

Even so, how does this compare with the risks of other voluntary activities, such as driving, smoking, unsafe sex, or mountaineering? How can we compare one such risk with another? Who can ‘feel’ or ‘fear’ a 1% risk? And how do we go about balancing risk and pleasure? Mathematics might help us to answer the first question, but the second just isn’t amenable to quantification. It’s a personal judegement, whether foolish or wise.

For reference, 150 people, on average, are killed annually by falling coconuts. This represents a lifetime risk of about 1 in 27,000. But it’s a risk that’s easily averted.

Here are some other risks (as published in 2007 by the New York Times):

Risk Annual Deaths Lifetime risk
Heart disease 652,486 1 in 5
Cancer 553,888 1 in 7
Stroke 150,074 1 in 24
Hospital infections 99,000 1 in 38
Flu 59,664 1 in 63
Car accidents 44,757 1 in 84
Suicide 31,484 1 in 119
Accidental poisoning 19,456 1 in 193
MRSA (resistant bacteria) 19,000 1 in 197
Falls 17,229 1 in 218
Drowning 3,306 1 in 1,134
Bike accident 762 1 in 4,919
Air/space accident 742 1 in 5,051
Excessive cold 620 1 in 6,045
Sun/heat exposure 273 1 in 13,729
Shark attack 62 1 in 60,453
Lightning 47 1 in 79, 746
Train crash 24 1 in 156,169
Fireworks 11 1 in 340,733

So, drinking more than fourteen units of alcohol a week means that you’re slightly more likely to die in a car accident than as a result of alcohol consumption.  Does that help? Driving and drinking (though never at the same time) are both pleasures that most of us wouldn’t entirely forego.

“Drinking any level of alcohol regularly carries a health risk for anyone, but if men and women limit their intake to no more than 14 units a week it keeps the risk of illness like cancer and liver disease low,” said Sally Davies, the Chief Medical Officer for England.

Liverpool University’s Professor Matt Field said the advice will help shape people’s choices and added that risk is involved in many of our daily activities. “Any amount of alcohol consumption carries some risk,” the Professor of Addiction said. “However, it is important to bear in mind that most activities that people undertake on a daily basis – e.g. driving to work – carry some risk, and people need to make informed choices about the level of risk that they are prepared to accept.”

It seems obvious to me that alcohol is bad for you. I’ve given it up for January, and after ten days I already feel the benefit – more energy, better sleep, slight weight loss, and so on. I’m not a heavy drinker (I’ve probably averaged about 21 units a week over the last year), but, on balance, I’ll accept the risk in return for the pleasure of a glass or two of a good red wine. I look forward to February.

Developing a Software Package – The Nightmare Continued


Last week I wrote some notes on what you need to think about before you start designing and developing a business software package (see Developing a Software Package). I suggested you shouldn’t even consider it if you’re of a timid or risk averse disposition. You’ll need more courage, more determination, more time and money than you ever imagined. You’ll need a thick skin, impervious to the disappointment and impatience of customers, colleagues and managers. It’s all much harder than you think.

I asked three questions:

  1. Who are your customers?
  2. Who are your competitors?
  3. How are you going to make it simple enough but flexible enough to fit a broad range of customer needs?


Here are a few more:

  1. Have you thought of the linguistic, national and currency issues?

If you’re ambitious and you see yourself selling to an international market, then think of what this means before you’ve written much code. The cost of trying to get this right at any later stage is terminal. So if you aim to provide multi-language capability, make sure your technology supports UNICODE (double-byte representation) at the database and software level. Find a Japanese friend to prove this aspect really works. Make sure you can handle transactions in more than one currency. In fact, think in terms of representing every transaction in your system in at least four currencies simultaneously (transaction currency, local currency, reporting currency, customer/supplier currency). And don’t forget to build sufficient flexibility to cover all the idiosyncratic national tax reporting issues you can think of.

  1. Have you thought about technology?

In this area, don’t try to be too clever. Make sure you choose uncontroversial but up-to-date technology. Be cloud ready and design the software so that it can run in multi-tenant mode (one copy of the software serving multiple clients safely and securely). You can’t go far wrong MS-SQL, IIS, Internet Explorer/Chrome/Firefox/Safari and Windows. Don’t, whatever you do, let your programmers seduce you into using something ‘better’. Don’t be on the leading edge, hitching your wagon to some promising technology that might fail to win market share. Your customers don’t want to be pioneers. Be just that little bit behind.

  1. How important is technical perfection?

It’s a cliché, but in software development, as elsewhere, ‘perfection is the enemy of the good’. If you aim to do things perfectly it’s going to take far too long, and you’ll always fail. So be aware of that when you’re starting. Set yourself guidelines. Have the good sense to know when something’s good enough.

  1. Have you thought about how you’ll manage the technical aspects of licensing?

If your package is modular, and you’ve priced it accordingly, then you’ll need a mechanism for restricting access to components of the system, even if your installation program installs the entire software suite and database. And you’ll need a way of limiting a license period, so that you’ve got some way of making your customer pay you.

  1. Have you thought about the techniques you’ll use for installation and upgrade?

Installation has to be fool proof. Don’t depend on your software falling into the hands of IT specialists. It has to be consumer proof too. Don’t depend on the user having to download additional components from Microsoft or other vendors to make it work. They won’t read the manuals, they won’t understand the error messages and they won’t do it.

Version control is also essential. So is easy upgrade. You’ve got to provide new functionality and bug fixes with easy installation and guaranteed forward compatibility.

Some final thoughts next week….

Mutual Frustration – Why do IT systems users wait so long for features that already exist?


I attended a conference recently where, by chance, I met someone who’s using the expense management system that I design – expense@work.  It’s always a little alarming when you meet a real user since you must expect them to be honest, and there are no better judges of what you’ve done. This one was direct:

‘I hate it,’ he said, with the kind of mock fury that told me that he knew he was exaggerating and didn’t really want me to go away and kill myself.

‘Why?’ I asked.

‘Well, it’s so out of date. I can’t attach images to my expense claims, and I can’t use it on a mobile device,’ and so on.

‘But you can,’ I said. ‘We’ve had those features for years.’

‘Then why haven’t we got them?’

‘I don’t know.’


It’s so frustrating, but this happens time and time again. And not only with our own software. We also sell and implement a financial system, SunSystems, and again, we often have to deal with users who want features that we have, but who aren’t getting them.

This is actually a widespread problem in system implementation and the end result seems to be unnecessary reputational damage for the software author.

Why does it happen and how can it be avoided?

It happens because system implementation is a lengthy, expensive and risky business and end users don’t often determine what’s on the list of features that they’re going to get. Sponsors and project managers on the client’s side have a highly controlled, and usually narrow, list of objectives, and their criteria of success won’t usually include the implementation of features that are merely ‘nice to have’ but not necessary.

That’s why ‘nice features’ don’t make the list during an initial implementation, but it doesn’t explain why nice new features don’t get implemented later as soon as they become available.

The problem is that once a system is implemented, the policy becomes ‘if it ain’t broke, don’t fix it’, so new versions with ever more up-to-date features, don’t get implemented either. And this is eminently sensible, because upgrades take time, often go wrong (for a while at least), and cost money. Upgrade projects are sometimes almost as large, expensive and risky as initial implementation projects, even if the software automates many aspects of the upgrade (such as updates to the database).

Software authors want their software to be liked by their end users. End users want ‘nice’ features. The obstacle lies between the two, in the conservatism of the client’s project managers and IT department.

Sadly, I can’t see what’s wrong with this. ‘Conservatism’ is a very sensible policy with business systems. The tragedy is that result is frustration on one side and unhappiness on the other. is there anything we can do about it?

I ask this question without knowing the answer. I wish I could find a way to deliver new features in software without risk or disturbance. But this is difficult. Business software isn’t like a desktop productivity tool. The problem is that what you do in one corner of the system can have unintended consequences in another corner. And when a system is implemented for a client it’s often integrated with lots of other systems, so a change in one corner of our part of the whole, can disturb a corner in another part that isn’t within our control, as authors of just one part, at all.

To some extent this problem is solved in ‘cloud’ or ‘hosted’ solutions, because authors then control the version that an end-user uses, and can introduce and publicise new features without obstruction from intervening project managers.

But ‘cloud’ and ‘hosted’ solutions aren’t always suitable when it comes to complex business software, especially when the software must be integrated with a client’s own systems. When there is deep integration, conservatism rules, and must do so.

And yet, it’s so frustrating to meet end-users and to have to repeat time and time again,’But our software CAN DO THAT!’

Any ideas?