Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development

Start Here

Quick Summary
A Simple Scenario
The Risk Landscape


Please star this project in GitHub to be invited to join the Risk First Organisation.


Consuming Hacker News 14 May 2019
Twitter Cards 22 March 2019
Next - Scrum? 7 March 2019
Available On Amazon 25 February 2019
New Proof 10 February 2019


Click Here For Details

Dependency Risk

Dependency Risk is the risk you take on whenever you have a dependency on something (or someone) else.

One simple example could be that the software service you write might depend on hardware to run on: if the server goes down, the service goes down too. In turn, the server depends on electricity from a supplier, as well as a network connection from a provider. If either of these dependencies aren’t met, the service is out of commission.

Dependencies can be on events, people, teams, work, processes, software, services, money and pretty much any resource, and while every project will need some of these, they also add risk to any project because the reliability of the project itself is now a function involving the reliability of the dependency.

In order to avoid repetition, and also to break down this large topic, we’re going to look at this over 7 sections:

Why Have Dependencies?

Luckily for us, the things we depend on in life are, for the most part, abundant: water to drink, air to breathe, light, heat and most of the time, food for energy.

This isn’t even lucky though: life has adapted to build dependencies on things that it can rely on.

Although life exists at the bottom of the ocean around hydrothermal vents, it is a very different kind of life to ours and has a different set of dependencies given its circumstances.

This tells us a lot about Dependency Risk right here:

Let’s look at four types of risk that apply to every dependency: Fit, Reliability, Invisibility and Complexity.

Fit Risk

In order to illustrate some of the different Dependency Risks, let’s introduce a running example: trying to get to work each day. There are probably a few alternative ways to make your journey each day, such as by car, walking or by bus. These are all alternative dependencies but give you the same feature: they’ll get you there.

Normally, we’ll use the same dependency each day. This speaks to the fact that each of these approaches has different Feature Fit Risk. Perhaps you choose going by bus over going by car because of the risk that owning the car is expensive, or that you might not be able to find somewhere to park it.

Two-Dimensions of Feature Fit for the bus-ride

But there are a couple of problems with buses you don’t have with your own car, as shown in the above diagram. A bus might take you to lots of in-between places you didn’t want to go, which is Conceptual Integrity Risk and we saw this already in the section on Feature Risk. Also, it might not go at the time you want it to, which is Feature-Fit-Risk.

What this shows us is that Fit Risks are as much a problem for the suppliers of the dependency (the people running the bus service) as they are for the people (like you or I) using the dependency.

Reliability Risk

This points to the problem that when we use an external dependency, we are at the mercy of its reliability.

“… Reliability describes the ability of a system or component to function under stated conditions for a specified period of time.” - Reliability Engineering, Wikipedia

Reliability Risk

It’s easy to think about reliability for something like a bus: sometimes, it’s late due to weather, or cancelled due to driver sickness, or the route changes unexpectedly due to road works.

In software, it’s no different: unreliability is the flip-side of Feature Implementation Risk. It’s caused in the gap between the real behaviour of the software and the expectations for it.

There is an upper bound on the reliability of the software you write, and this is based on the dependencies you use and (in turn) the reliability of those dependencies:

This kind of stuff is encapsulated in the science of Reliability Engineering. For example, Failure Mode and Effects Analysis (FEMA):

“…was one of the first highly structured, systematic techniques for failure analysis. It was developed by reliability engineers in the late 1950s to study problems that might arise from malfunctions of military systems. “ - FEMA, Wikipedia

This was applied on NASA missions, and then in the 1970’s to car design following the Ford Pinto exploding car affair. But establishing the reliability of software dependencies like this would be hard and expensive. We are more likely to mitigate Reliability Risk in software using testing, redundancy and reserves, as shown in the diagram above.

Additionally, we often rely on proxies for reliability. We’ll look at these proxies (and the way in which software projects signal their reliability) in much more detail in the section on Software Dependency Risk.

Invisibility Risk

Dependencies (like the bus) make life simpler for you by taking on complexity for you.

In software, dependencies are a way to manage Complexity Risk. The reason for this is that a dependency gives you an abstraction: you no longer need to know how to do something, (that’s the job of the dependency), you just need to interact with the dependency properly to get the job done. Buses are perfect for people who can’t drive, after all.

Dependencies help with complexity risk, but come with their own attendant risks

But (as shown in the above diagram) this means that all of the issues of abstractions that we covered in Communication Risk apply. For example, there is Invisibility Risk because you probably don’t have a full view of what the dependency is doing. Nowadays, bus stops have a digital “arrivals” board which gives you details of when the bus will arrive, and shops publish their opening hours online. But, abstraction always means the loss of detail (the bus might be two minutes away but could already be full).

Dependencies And Complexity

In Rich Hickey’s talk, Simple Made Easy he discusses the difference between simple software systems and easy (to use) ones, heavily stressing the virtues of simple over easy. It’s an incredible talk and well worth watching.

But: living systems are not simple. Not anymore. They evolved in the direction of increasing complexity because life was easier that way. In the “simpler” direction, life is first harder and then impossible, and then an evolutionary dead-end.

Depending on things makes your job easier. But the Complexity Risk hasn’t gone away: it’s just transferred to the dependency. It’s just division of labour and dependency hierarchies, as we saw in Complexity Risk.

Our economic system and our software systems exhibit the same tendency-towards-complexity. For example, the television in my house now is vastly more complicated than the one in my home when I was a child. But, it contains much more functionality and consumes much less power and space.

Managing Dependency Risk

Arguably, managing Dependency Risk is what Project Managers do. Their job is to meet the project’s Goal by organising the available dependencies into some kind of useful order.

There are some tools for managing dependency risk: Gantt Charts for example, arrange work according to the capacity of the resources (i.e. dependencies) available, but also the dependencies between the tasks. If task B requires the outputs of task A, then clearly task A comes first and task B starts after it finishes. We’ll look at this more in Process Risk.

We’ll look in more detail at project management in Part 3, later. But now, let’s get into specifics with Scarcity Risk.

Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.