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, processes, software, services, money and pretty much any resource, and while every project will need some of those, 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:
- In this first section will look at dependencies in general, and some of the variations of Dependency Risk.
- Next, we'll look at Scarcity Risk, because time and money are scarce resources in every project.
- We'll cover Deadline Risk, and discuss the purpose of Events and Deadlines, and how they enable us to coordinate around dependency use.
- Then, we'll move on to look specifically at Software Dependency Risk, covering using libraries, software services and building on top of the work of others.
- After, we'll take a look at Process Risk, which is still Dependency Risk, but we'll be considering more organisational factors and how bureaucracy comes into the picture.
- Next, we'll take a closer look at Boundary Risk and Dead-End Risk. These are the risks you face in making choices about what to depend on.
- Finally, we'll wrap up this analysis with a look at some of the specific problems around depending on other people or businesses in Agency Risk.
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 us, and has a different set of dependencies given it's circumstances.
This tells us a lot about Dependency Risk right here:
- On the one hand, depending on something else is very often helpful, and quite often essential. (For example, all life seem to depend on water).
- However, as soon as you have dependencies, you need to take into account of their reliability. (Living near a river or stream gives you access to fresh water, for example).
- Successful organisms adapt to the dependencies available to them (like the thermal vent creatures).
- There is likely to be competition for a dependency when it is scarce (think of droughts and famine).
So, dependencies are a trade-off. They give with one hand and take with the other. Our modern lives are full of dependency (just think of the chains of dependency needed for putting a packet of biscuits on a supermarket shelf, for example), but we accept this risk because it makes life easier.
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 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 the bus will take you to lots of in-between places you didn't want to go. This is also Fit Risk and we saw this already in the section on Feature Risk. There, we considered two problems:
- The feature (or now, dependency) doesn't provide all the functionality you need. This was Fit Risk. An example might be your supermarket not stocking everything you want to buy.
- The feature / dependency provides far too much, and you have to accept more complexity than you need. This was Conceptual Integrity Risk. An example of this might be the supermarket being too big, and you spend a lot longer navigating it than you wanted to.
This points at 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
Unreliability manifests itself when a dependency fails you under certain sets of circumstances. 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:
- If a component A depends on component B, unless there is some extra redundancy around B, then A can't be more reliable than B.
- Is A or B a Single Point Of Failure in a system?
- Are there bugs in B that are going to prevent it working correctly in all circumstances?
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.
Because of Trust Risk and Invisibility Risk, we cannot always establish reliability for a dependency, and this is a huge area of concern in software when choosing dependencies, as we will see in the section on Software Dependency Risk.
In the Communication Risk section we looked at Marketing Communications and talked about the levels of awareness that you could have with a dependency.
Let's apply this to our Bus scenario:
- Am I aware that there is public transport in my area?
- How do I find out about the different options?
- How do I choose between buses, taxis, cars etc.
- How do I understand the timetable, and apply it to my problem?
- Is it a reliable enough solution?
Finding out about bus schedules is easy. But in a large company, Communication Risk and especially Invisibility Risk are huge problems. This tends to get called "Silo Mentality", that is, ignoring what else is going on in other divisions of the company or "not invented here" syndrome:
"In management the term silo mentality often refers to information silos in organisations. Silo mentality is caused by divergent goals of different organisational units." - Silo Mentality, Wikipedia
Ironically, more communication might not be the answer, because even with more communication you still cannot determine reliability. If channels are provided to discover functionality in other teams you can still run into Trust Risk (why should I believe in the quality of this dependency?) or Agency Risk (unwarranted self-promotion).
While dependencies (like the bus, or the supermarket) make life simpler for you, they do this by taking on complexity for you.
In our software, Dependencies are a way to manage Complexity Risk, and we'll investigate that in much more detail in Software Dependency 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 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 some 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. 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.
Arguably, managing Dependency Risk is what Project Managers do. Their job is to meet the 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 the practices part, later. But now let's get into the specifics with Scarcity Risk.
