Staging And Classifying

Our tour is complete.

We've collected on this journey around the Risk Landscape a (hopefully) good, representative sample of Risks and where to find them. But if we are good collectors, then before we're done we should Stage our collection on some solid [Mounting Boards], and do some work in classifying what we've seen.

If you've been reading closely, you'll notice that a number of themes come up again and again within the different sections. For example, concepts like Fit, Abstraction, Evolution. Although we've been looking at patterns of risk across software projects, it's time to look at the patterns within the patterns.

First, A Recap

tbd. list of risks, broken down

Some Observations

The Power Of Abstractions

Abstraction appears as a concept continually throughout the book, whether we are looking at Communication, Complexity Metrics, Map and Territory Risk or how it causes Boundary Risk. And, so far, we've looked at some complicated examples of abstractions, such as network protocols, dependencies on technology or Business Processes.

There's a good reason for this repetition. Abstraction is at the heart of everything we do within software. So, let's now generalize what is happening with abstraction, but have in mind a really simple example: having a name for something. So, at the simplest end, you might be simply naming a pattern of behaviour we see in the real world, such as "Binge Watching" or "Remote Working", or naming a category of insects as "Beetles".

Using An Existing Abstraction means:

• Mitigating Feature Risk: Because the abstraction is providing you with something useful.
• Living with Dependency Risk: We depend on a word in our language, or a function in our library, or a service on the internet. But all of these things are unreliable. The word might not communicate what you want it to, or be understood by the audience, the function might not work, the service might be down.
• Accepting Evolution. That language changes and evolves, and the words you are using now might not always mean what you want them to mean. Software too changes and evolves. We've seen this in Red Queen Risk, Feature Drift Risk, Regression Risk and Protocol Risk.
• Accepting [Coordination Risk](Coordination Risk). Where a Dependency has Agency, we need to consider how to work with it.

Inventing A New Abstraction means:

• Creating a Feature. These abstractions are Features in the sense that other people can choose to use them, if they fit their requirements.
• Increasing Complexity. Because, the more words we have, the more complex the language is.
• Creating a Boundary. By naming something, you implicitly create a boundary, because the world is now divided into "things which are X" and "things which are not X". Sometimes, this abstraction may literally end up having a physical boundary to enforce this division (such as, "My Property / Not My Property"). Boundary Risk is created by abstractions.
• Creating a Protocol. At the very simplest level (again), this is just introducing new words to a language. Therefore, we create Protocol Risk: what if the person we are communicating with _doesn't know this word?

Choosing Between Abstractions means:

• Overcoming a Learning Curve: Because you have to learn a name in order to use it (whether a function, a dog, or the name of someone at a party).
• Accepting Boundary Risks. Just using a single word means accepting the whole ecosystem of the language the word is in. Using French words means the Boundary Risk of the French Language.
• Accepting Map And Territory Risk. Because the word refers to the concept of the thing, and not the thing itself.

Your Feature Risk is Someone Else's Dependency Risk

In the Feature Risk section, we looked at the problems of supplying a dependency to someone else: you've got to satisfy a demand Market Risk, and ensure a close fit with requirements Conceptual Integrity Risk. The section on Production Risk went further, looking at specific aspects of being the supplier of an IT service as a dependency.

However, over the rest of the Dependency Risk sections, we looked at this from the point of view of being a client to someone else: you want to find trustworthy, reliable dependencies that don't give up when you least want them to.

So Feature Risk is Dependency Risk: they’re two sides of the same coin. You face Dependency Risk when you’re a client, Feature Risk when you’re the supplier.

We've looked at three dimensions of Feature Risk:

• Fit
• Evolution
• Audience

(recap this)

Dependency Risk has three dimensions too:

• Schedule (things happening in time, running out of stuff. e.g I need enough money to get this done, etc. I need enough patience, enough loyalty, trust, entente.)
• Technology (depending on software, hardware, etc. )
• Organisation (arrangements of people, processes, product)
• Agency (people/machines/processes/organisations doing what you asked, working with you)

Using a dependency requires learning a protocol. You have to learn to use it. Maybe it learns you. This requires changes to your internal model.

Internal Model - Communication -- Dependency Goal

3. Coordination Risk And The Garden Of Eden

• similar to _threading/deadlocking issues
• Coordination is how you deal with abstractions. and this means communication.

tbd diagram: abstractions -> agency -> coordination -> communication

One thing that should be apparent is that there are similarities in the risks between all the kinds of

• draw a diagram of this system. mark on all the different risks using numbers. mention specifically that since this is a diagram, it is a "map".

Towards A Periodic Table Of Risks

tbd, diagram, explanatory text.

Dependencies, Features, Complexity etc.

Patterns

As we said at the start, Risk-First is all about developing A Pattern Language. We can use the terms like "Feature Risk" or "Learning Curve Risk" to explain phenomena we see on software projects. If we want to De-Risk our work, we need to be able to explain what the risks are, and what we expect to do about them.

So, lastly in part 2 let's put our language to work, and look at some past project failures. Can we apply our lexicon to them?

On to Stories Of Failure.