When you’re learning the game of software development, you probably never think of software risk. You write a few lines of code, then you celebrate seeing “Hello World” on the screen. Rinse, repeat as you build ever more impressive stuff, teaching yourself the craft.
But then you take a job doing this stuff, and that changes in a hurry. Sure, it’s mostly organizational leadership that tosses around the term “software risk” in meetings and looks to quantify it. But anyone with skin in the game feels the weight of risk acutely. What if the user types in something we don’t expect? What if the release doesn’t go well? Will we get frantic calls at 3 AM about this?
When commerce depends on the software that you write, the possibilities for problems seem endless. Risk is everywhere.
What is Risk?
Before we look at how to reduce risk, let’s take a crack at meaningfully defining it. In the world of commerce or investment, risk refers to the possibility of an investment losing value. And while that’s somewhat applicable to the commercial world in which software resides, we need to generalize a bit. Let’s take this definition from the dictionary to cover our bases:
Someone or something that creates or suggests a hazard.
Truly, this is what we mean when we talk about software risk. Sure, hazardous production behavior of the software might result in financial damages to your company. If you view the software as a commodity (which I don’t really recommend), you could even say that the presence of defects reduces its value. But the investment definition fits awkwardly. Really, we’re talking about hazard.
Software is really complicated. We build this stuff, reason about it the best we can, test it out, then send it to production like an ocean liner on its maiden voyage. And when it gets to that metaphorical ocean, a lot of unexpected things can go dramatically wrong. We talk about this as risk.
Defining Low Impact
Of course, we’re not helpless. As software development shops, we can do a lot to mitigate this risk, and we frequently do. Here are some common suggestions that you’ll hear:
- Get a good, robust, automated test suite in place.
- Ramp up exploratory QA and load/stress testing efforts.
- Break the code apart into more isolated, decoupled microservices.
- Switch methodology and “go agile.” (Or go the other direction and plan harder)
- Hire experts to come in for an assessment.
Everything there can absolutely help. But if you’re working in a lot of small-to-medium-sized shops, these things tend also to be pipe dreams: “Oh, sure, we’ll just tell our customers to wait a while and put in a bunch of tests, go agile, and refactor the whole application. And when we’re done with that, we’ll get to work on building that morale-boosting waterslide from the third floor to the first floor, too.”
So instead of the traditional approaches that require significant investment and the overhaul of your current approach, let’s look at some relatively low-impact things you can do. While these require time investment and behavior changes, all of them are things you can do with relatively minor cash investment and relatively minimal disruption to your general work.