The Risk Landscape

In the previous section, we saw how Lean Software Development owed its existence to production-line manufacturing techniques developed at Toyota. And we saw that the Waterfall approach originally came from engineering. If Risk-First is anything, it’s about applying the techniques of Risk Management to the discipline of Software Development (there’s nothing new under the sun, after all).

One key activity of Risk Management we haven’t discussed yet is categorizing risks. Thus, Part 2 of Risk-First is all about developing categories of risks for use in Software Development.

The Risk Landscape Again

In Meeting Reality, we looked at the concept of the Risk Landscape, and how a software project tries to navigate across this landscape, testing the way as it goes, and trying to get to a position of more favourable risk.

It’s tempting to think of our Risk Landscape as being like a Fitness Landscape. That is, you have a “cost function” which is your height above the landscape, and you try and optimise by moving downhill in a Gradient Descent fashion.

However, there’s a problem with this: as we said in Evaluating Risk, we don’t have a cost function. We can only guess at what risks there are. We have to go on our experience. For this reason, I prefer to think of the Risk Landscape as a terrain which contains fauna and obstacles (or, specifically Boundaries).

Just as I can tell you that the landscape outside your window will probably will have some trees, fields and buildings, and that the buildings are likely to be joined together by roads, we can make generalisations about risks too.

Why Should We Categorise The Risks?

A lot of knowledge and understanding of the world starts by naming and categorising things.

If we were studying insects, this might be a guide giving you a description and a picture of each insect, telling you where to find it and how it lives. That doesn’t mean that this is all there is to know. Just as a scientist could spend an entire lifetime studying a particular species of bee, each of the risks we’ll look at really has a whole sub-discipline of Computer Science attached to it, which we can’t possibly hope to cover in any great depth.

As software developers, we can’t hope to know the specifics of the whole discipline of Complexity Theory, or Concurrency Theory. But, we’re still required to operate in a world where these things exist. So, we may as well get used to them and ensure that we respect their primacy. We are operating in their world, so we need to know the rules.

Once we can spot and name different types of risk we can then think about their characteristics and how to manage or avoid them. Over the following pages, we’re going to take a tour of various different categories of risks, exploring their characteristics and sometimes suggesting actions to take to deal with them. But foremost, this is a “spotters’ guide” to software risks and where to find them.

Our Tour Itinerary

Below is a table outlining the different risks we’ll see. There is an order to this: the later risks are written assuming a familiarity with the earlier ones. Hopefully, you’ll stay to the end and see everything, but you’re free to choose your own tour if you want to.

After each stop on the tour, in Staging and Classifying we’ll have a recap about what we’ve seen and make some guesses about how things fit together.

Causation & Correlation

Although we’re going to try and categorise the kinds of things we see on this Risk Landscape, this isn’t going to be perfect, because:

• One risk can “blend” into another just like sometimes a “field” is also a “car-park” or a building might contain some trees (but isn’t a forest).
• As we know from Part 1, mitigating one risk probably means accepting another.
• There is causation and correlation between different risks: one risk may cause another, or two risks might have the same underlying cause.

Risk is messy. It’s not always easy to tease apart the different components of risk and look at them individually. Let’s look at a high-profile recent example to see why.

The Financial Crisis

In the Financial Services industry, whole departments exist to calculate things like:

• Market Risk: the risk that the amount some asset is going to change in value.
• Credit Risk: the risk that someone who owes you a payment at a specific point in time might not pay it back.
• Liquidity Risk: the risk that you can’t find a market to sell/buy something, usually leading to a shortage of ready cash.

In the financial crisis of 2007, these models of risk didn’t turn out to be much use. Although there are lots of conflicting explanations of what happened, one way to look at it is this:

• Liquidity difficulties (i.e. amount of cash you have for day-to-day running of the bank) caused some banks to not be able to cover their short term payment obligations.
• This caused credit defaults (the thing that Credit Risk measures were meant to guard against) even though the banks technically were solvent.
• Once credit defaults started, this worried investors in the banks, which had massive Market Risk impacts that none of the models foresaw.

All the Risks were correlated. That is, they were affected by the same underlying events, or each other.

It’s like this with software risks, too, sadly. For example, Operational Risk is going to be heavily correlated with Complexity Risk: the more complex your operation, the more risky it will be. In the Risk-First diagrams, we will sometimes show correlation or causation with an arrow, like in the diagram above.

We’re all Naturalists Now

Just as naturalists are able to head out and find new species of insects and plants, we should expect to do the same. Risk-First is by no means a complete picture - it’s barely a sketch.

It’s a big, crazy, evolving world of software. Help to fill in the details. Report back what you find.

So, let’s get started with Feature Risk.