Meeting Reality

In this section, we will look at how exposing your Internal Model to reality is in itself a good risk management technique.

Revisiting the Model

In A Simple Scenario, we looked at a basic model for how Reality and our Internal Model interacted with each other: we take action based on out Internal Model, hoping to change Reality with some positive outcome.

And, in Development Process we looked at how we can meet with reality in different forms: Analysis, Testing, Integration and so on, and saw how the model could work in each stage of a project.

Finally, in Software Project Scenario we looked at how we could use this model on a day-to-day basis to inform what we should do next.

So, it should be no surprise to see that there is a recursive nature about this:

1. The actions we take each day have consequences: they expose new Hidden Risks, which inform our Internal Model, and at the same time, they change reality in some way (otherwise, what would be the point of doing them?)
2. The actions we take towards achieving a Goal In Mind each have their own Goal In Mind. And because of this, when we take action, we have to consider and evaluate the Hidden Risks exposed by that action. That is, there are many ways to achieving a goal, and these different ways expose different Hidden Risks.

So, let's see how this kind of recursion looks on our model. Note that here, I am showing just one possible action, in reality, you'll have choices.

.

Hopefully, if you've read along so far, this model shouldn't be too hard to understand. But, how is it helpful?

"Navigating the Risk Landscape"

So, we often have multiple ways of achieving a Goal In Mind.

What's the best way?

I would argue that the best way is the one which accrues the least risk to get it done: each action you take in trying to achieve the overall Goal In Mind will have it's Attendant Risks, and it's the experience you bring to bear on these that will help you navigate through them smoothly.

Ideally, when you take an action, you are trading off a big risk for a smaller one. Take Unit Testing for example. Clearly, writing Unit Tests adds to the amount of development work, so on it's own, it adds Schedule Risk. However, if you write just enough of the right Unit Tests, you should be short-cutting the time spent finding issues in the User Acceptance Testing (UAT) stage, so you're hopefully trading off a larger Schedule Risk from UAT and adding a smaller risk to Development.

Sometimes, in solving one problem, you can end up somewhere worse: the actions you take to solve a higher-level Attendant Risk will leave you with a worse Attendant Risks. Almost certainly, this will have been a Hidden Risk when you embarked on the action, otherwise you'd not have chosen it.

An Example: Automation

diagram of how automation reduces process risk, but increases complexity?

Another Quick Example: MongoDB

On a recent project in a bank, we had a requirement to store a modest amount of data and we needed to be able to retrieve it fast. The developer chose to use MongoDB for this. At the time, others pointed out that other teams in the bank had had lots of difficulty deploying MongoDB internally, due to licensing issues and other factors internal to the bank.

Other options were available, but the developer chose MongoDB because of their existing familiarity with it: therefore, they felt that the Hidden Risks of MongoDB were lower than the other options, and disregarded the others' opinions.

The data storage Attendant Risk was mitigated easily with MongoDB. However, the new Attendant Risk of licensing bureacracy eventually proved too great, and MongoDB had to be abandoned after much investment of time.

This is not a criticism of MongoDB: it's simply a demonstration that sometimes, the cure is worse than the disease. Successful projects are always trying to reduce Attendant Risks.

The Cost Of Meeting Reality

Meeting reality is costly, for example. Going to production can look like this:

• Releasing software
• Training users
• Getting users to use your system
• Gathering feedback

All of these steps take a lot of effort and time. But you don't have to meet the whole of reality in one go - sometimes that is expensive. But we can meet it in "limited ways".

In all, to de-risk, you should try and meet reality:

• Sooner, so you have time to mitigate the hidden risks it uncovers
• More Frequently: so the hidden risks don't hit you all at once
• In Smaller Chunks: so you're not overburdened by hidden risks all in one go.
• With Feedback: if you don't collect feedback from the experience of meeting reality, hidden risks stay hidden.

YAGNI

As a flavour of what's to come, let's look at YAGNI, an acronym for You Aren't Gonna Need It. Martin Fowler says:

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

This principle was first discussed and fleshed out on Ward's Wiki

The idea makes sense: if you take on extra work that you don't need, of course you'll be accreting Attendant Risks.

But, there is always the opposite opinion: You Are Gonna Need It. As a simple example, we often add log statements in our code as we write it, though following YAGNI strictly says we should leave it out.

Which is right?

Now, we can say: do the work if it mitigates your Attendant Risks.

• Logging statements are good, because otherwise, you're increasing the risk that in production, no one will be able to understand how the software went wrong.
• However, adding them takes time, which might introduce Schedule Risk.

So, it's a trade-off: continue adding logging statements so long as you feel that overall, you're reducing risk.

Do The Simplest Thing That Could Possibly Work

Another mantra from Kent Beck (originator of the Extreme Programming methodology, is "Do The Simplest Thing That Could Possibly Work", which is closely related to YAGNI and is about looking for solutions which are simple. Our risk-centric view of this strategy would be:

• Every action you take on a project has it's own Attendant Risks.
• The bigger or more complex the action, the more Attendant Risk it'll have.
• The reason you're taking action at all is because you're trying to reduce risk elsewhere on the project
• Therefore, the biggest payoff is whatever action works to remove that risk, whilst simultaneously picking up the least amount of new Attendant Risk.

So, "Do The Simplest Thing That Could Possibly Work" is really a helpful guideline for Navigating the Risk Landscape.

Summary

So, here we've looked at Meeting Reality, which basically boils down to taking actions to manage risk and seeing how it turns out:

• Each Action you take is a step on the Risk Landscape
• Each Action is a cycle around our model.
• Each cycle, you'll expose new Hidden Risks, changing your Internal Model.
• Preferably, each cycle should reduce the overall Attendant Risk of the Goal

Surely, the faster you can do this, the better? Let's investigate...