Unless you’re a TV presenter, it’s quite easy to understand that risk is nearly always present but is mostly manageable. Often this is inescapable – no amount of effort will reduce the risk to zero. The question is, should we ever try? Should zero risk be the goal of any undertaking?

It depends, of course. You will struggle to make a business profit without taking risks. That’s accepted. But what if you are developing the control system for a passenger aircraft? What is the acceptable risk in that undertaking? One fault in your output could have fatal consequences. Should you pursue zero risk in that sort of project? Well, aircraft control systems are complex and there is a limit to how thoroughly they can be tested (although that limit is quite high). You can take action to ensure that many sources of error are eliminated systematically, but I don’t believe you can ever get to 100% certainty that an aircraft control system is safe. At some point you have to install your system on a plane and watch it take off.

The things you can do to make that experience less nerve-racking are ordinary bits of good engineering practice. Lessons learned from centuries of building stuff from wood, stone, iron, steel, concrete and glass can be translated into software projects fairly seamlessly. Transparent project management, repeatable processes, eliminating unnecessary manual tasks, identifying valuable metrics, keep it as simple as possible, etc. The important point is to understand where the risk arises and mitigate it whenever it is sensible to do so.

And that’s the point I’ve been trying to get to. There are many sources of risk and not all are equal. If a risk can be mitigated cost effectively then you should do it. The key word is “cost-effective” and the trick is to get the cost-benefit sums right. This can lead you to some surprising results. The point my colleague was making was that if you have too few errors after a code release, you may be spending too much on mitigating your project risks. You could have delivered the release earlier or more cheaply. How do you compare the value of expediting the release with the downside of delivering buggy software?

The savings are relatively clear: if you deliver your software earlier or with fewer resources then there are direct and measurable cost savings. The other factor is opportunity cost – the sooner you deliver your software, the sooner it can start earning money for you or your customer. That loss of revenue (or loss of downstream cost savings) can be very significant and is certainly a factor in your calculations.

How do you measure the downside? This is less clear because the errors are not predictable. One disastrous error could wipe out all the supposed benefits of the entire project. You could analyse the maximum loss from a disastrous error then try to estimate how likely it is to occur. For a trading system this should be doable – what is the effect of mispricing a trade by an order of magnitude? The maximum loss could be terrifying, but you can take steps to reduce the likelihood of it happening: (i) release code frequently so each release is only an incremental change from the previous one, (ii) pilot your new version with a restricted set of expert users, (iii) build sanity checks into the software to raise an alert when an unlikely event happens.

I guess you are comparing the direct savings of your aggressive delivery schedule with the premium you would pay to insure yourself against the loss due to delivering bad software. The insurance premium will be lower if you can make the event less likely. You should take the risk if the savings exceed the premium. That’s about as clear as I can make it.

So anything you can do to mitigate risk with only a small cost, you should do. Definitely. Errors that arise from easily avoidable risk are just plain stupid and unprofessional. Doing things manually that you could easily automate, writing code in a bad style, using new technology just because it’s new – these are commonplace sources of error which can be eliminated by adopting simple hygiene measures.

On the other hand, taking expensive traders off a desk to spend time testing your new software in a test environment may not be such a good investment. It prevents them earning money (so it is not popular with them) and you are unlikely to get their full attention. So long as they understand and accept the risk of using software they have not tested personally then that is a business decision for them to make. This is an acceptable, managed risk.

So we get used to this picture of risk being all or nothing, black or white, safe or unsafe. Look at this report celebrating 30 years of the UK’s Health & Safety Executive (HSE):

“HSC’s annual report for 1977/78 states: ‘Our overriding concern is… to stimulate awareness of the risks and encourage the joint participation of workers and management in efforts to eliminate them.’ In 2004, the mission for HSC and HSE is to work with LAs ‘to protect people’s health and safety by ensuring that risks in the changing workplace are properly controlled’. The style may be different and the message broader but the core objective is essentially the same.”

Really? Is eliminating risk really the same as controlling it? I would say absolutely not, and the 2004 mission statement is a huge improvement on the 1977 version. The fact that the HSE’s own self-congratulatory pamphlet fails to point out the difference is an assumption by them that their target audience can’t understand the difference.

So we are led to a situation where an acceptance of risk is regarded as a Bad Thing. Gamblers and traders and other disreputable characters embrace risk. If the man in the street contemplates taking a financial risk, the regulator insists on apocalyptic warnings being read to him. If a popular investment turns out not to have been such a good idea after all, the newspapers blame the financial services industry or the government or the company selling the instrument, never giving the actual small investors credit for knowing what risk they were accepting when they bought it.

I think it’s a damaging mindset and it seems to be rooted in 1970s thinking: that’s when the HSE was invented, that’s when comprehensive schools started eliminating competition from sports periods, that’s when licenses became necessary for bingo and gaming machines. Hopefully that sort of thinking has had its day and we can start taking a more mature attitude to everyday risk and the way we communicate it.

I’m reminded of a scientist I once heard on the radio, who perceptively complained that although arts programmes are allowed to assume some prior knowledge on the part of the viewer or listener, science programmes have to explain everything from scratch every time. In other words, you can talk about Baudrillard as if everybody’s read him but woe betide you if you mention a probability distribution without explaining in laborious detail what it is. Go ahead and quote Descartes on philosophy but don’t dare mention cartesian geometry.

Anyway, I was trying to get to a point where I could start writing about risk management of projects but I seem to have come to a natural break anyway. More later.