In this section, we will look at how exposing your Internal Model to reality is in itself a good risk management technique.
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.
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.
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.
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.
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.
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.
Meeting reality in full is costly. For example, going to production can look like this:
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:
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 following YAGNI strictly says we shouldn’t.
Now, we can say: do the work if there is a worthwhile Payoff.
So, it’s a trade-off: continue adding logging statements so long as you feel that overall, the activity pays off reducing overall risk.
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:
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:
So, here we’ve looked at Meeting Reality, which basically boils down to taking actions to manage risk and seeing how it turns out:
Could it be that everything you do on a software project is risk management? This is an idea explored in the next section.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.