Article summary
People are surprisingly weak at evaluating risk. People are even worse when dealing with risks that they haven’t experienced themselves.
A Smart but Imperfect Play
Let me give you a non-software example: Years back, I was trading stocks a bit. One of my early trades was a pharmaceutical company. High risk, high reward, right? At one point, my investment dropped by half.
At the time, I felt foolish for not buying more: If I were to dollar cost average here and the stock recovered, I could be up a lot.
But really… was I wrong? Not really. With hindsight, it is easy to think, “I won, so it must not have been risky” (or its sister fallacy, “I lost, so maybe that was riskier than I thought”). What actually happened back then doesn’t discount what might have happened—or what could happen in the future. The risk was real.
Preparing for New Risks
Every trade involves a risk, and every software project will encounter many risks, too. Some risks will materialize, and some won’t. While you can make some educated guesses about the odds, in the end, you just never know until something bad happens. When you look back at your projects, you always see the risks that affected you. But (as with my investment above) it’s very easy to discount the risks that didn’t bite.
The best solution is to take care and hedge your bets. We have many practices, from unit tests and monitoring to scheduling buffers, and other methods that provide some insurance against the kinds of risks we see in software projects.
Here are a few examples:
- Spend time building in diagnostic tools (see this previous post). Hopefully, your customers will not have problems you need to debug. But it means a lot to customers when you can respond quickly and effectively if something does go wrong.
- Spend time on automation. There are always changes, and being able to make them without manual and error-prone steps is always good.
- Spend time making developer tools friendly. I often skimp on tools meant for just me, but it’s really nice when things are friendly enough that another developer can jump right in when I’m ill, or that I can remember how to use it when I come back in a year.
- Spend time on spikes–even though that code is never shipped. Even if all you get is a more accurate estimate, predictability helps you hit release date targets.
None of these things are going to have obvious and immediate customer-facing value, and it can be hard to point to some specific mitigation and say, “That was worthwhile”—at least, when things don’t go wrong. But these strategies can help keep things more predictable, reduce variance, and reduce reliance on specific developers and their knowledge.
If your last project didn’t need any insurance, just be happy the coin flip came up in your favor. And keep using spikes, automation, diagnostics, tests, and such to keep your insurance premiums paid up for next time.