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:
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.
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.
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.
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
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:
“…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.
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.
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).
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.
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.