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.

It should be no surprise to see that there is a recursive nature about this: the actions we take each day have consequences, they expose new hidden risks which inform our Internal Model and at the same time change reality in some way. As a result, we then have to take new actions to deal with these new risks.

So, let’s see how this kind of recursion looks on our model.

.

Navigating the “Risk Landscape”

The diagram above shows just one possible action, in reality, you’ll have choices. 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 mitigates the most existing risk while accruing the least attendant risk to get it done.

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 its 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 Schedule Risk to Development. There are other benefits of Unit Testing too: once written, a suite of unit tests is almost cost-free to run repeatedly, whereas repeating a UAT is costly as it involves people’s time.

You can think of Taking Action as moving your project on a “Risk Landscape”: ideally, when you take an action, you move to some place with worse risk to somewhere more favourable.

Sometimes, you can end up somewhere worse: the actions you take to manage a risk will leave you with worse Attendant Risks afterwards. 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

For example, automating processes is very tempting: it should save time, and reduce the amount of boring, repetitive work on a project. But sometimes, it turns into an industry in itself, and consumes more effort than it’s worth.

Another 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.

This turned out to be a mistake: The internal 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.

Payoff

We can’t know in advance how well any action we take will work out. Therefore, Taking Action is a lot like placing a bet.

Payoff then is our judgement about whether we expect an action to be worthwhile: are the risks we escape worth the attendant risks we will encounter? We should be able to weigh these separate risks in our hands and figure out whether the Payoff makes a given Action worthwhile.

The fruits of this gambling are revealed when we meet reality, and we can see whether our bets were worthwhile.

The Cost Of Meeting Reality

Meeting reality in full 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. But we can meet it in a limited way which is less expensive.

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 over-burdened 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.

In Development Process, we performed a UAT in order to Meet Reality more cheaply and sooner. The cost of this is that we delayed the release to do it, adding risk to the schedule.

Practice 1: YAGNI

As a flavour of what’s to come, let’s look at YAGNI, an acronym for You Aren’t Gonna Need It:

YAGNI originally is an acronym that stands for “You Aren’t Gonna Need It”. It is a mantra from Extreme Programming 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”. - YAGNI, Martin Fowler

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 (so we can trace what happened when things go wrong), though strictly following YAGNI strictly says we shouldn’t.

Which is right?

Now, we can say: do the work if there is a worthwhile Payoff.

• 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, the activity pays off reducing overall risk.

Practice 2: 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 an excellent razor for avoiding over-engineering. At the same time, by adding “Could Possibly”, Kent is encouraging us to go beyond straightforward iteration, and use our brains to pick apart the simple solutions, avoiding them if we can logically determine when they would fail.

Our risk-centric view of this strategy would be:

• Every action you take on a project has its 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 likely to be the one with the least Attendant Risk.
• So, usually this is going to be the simplest thing.

So, “Do The Simplest Thing That Could Possibly Work” is really a helpful guideline for Navigating the Risk Landscape, but this analysis shows clearly where it’s left wanting:

• Don’t do the simplest thing if there are other things with a better Payoff available.

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 exposes new Hidden Risks, changing your Internal Model.
• Ideally, each action should reduce the overall Attendant Risk on the project (that is, puts it in a better place on the Risk Landscape

Could it be that everything you do on a software project is risk management? This is an idea explored in the next section.