I wanted to spend some time exploring risk. How we observe and react to risk during software development directly relates to whether we’re sloppy, overdoing it, or just right. Just enough architecture is a bit of a humorous tautology, but that belies the importance of being able to identify and mitigate risk appropriately.
What is Risk?
From a formal engineering perspective, risk is the probability of a failure multiplied by its perceived impact. More colloquially, risks are the things that could go wrong with your project.
There are two fundamental types of risk: software engineering risks, and project management risks. Engineering risks are the ones you’re probably most accustomed too; risks related to the design and construction of software. Project management risks, on the other hand, relate to the scheduling and delivery of the aforementioned software. You might not be accustomed to considering management risks–I even know some developers who emphatically state it is not their job–but rest assured delivery of the software itself is your concern. In fact, “the major problems of our work are not so much technological as sociological in nature” (Peopleware).
How does knowing your risks help?
As G.I. Joe public-service announcements told us “knowing is half the battle.” This couldn’t be any more true of risks. Having a good handle on risks is the difference between riding a bike with one eye open as opposed to two. Sure, with one eye open you can definitely grok or even avoid a good number of risks. With two eyes open, however, you have perspective. You’ll know how far you are from each risk, and how they’re moving relative to your velocity.
To be less abstract: knowing your risks gives you the ability to prioritize in the large, and focus in the small. As you plan your project or iterations, you’ll have a 10,000 foot view of how your risks relate to your features/goals. As you work on a feature you’ll know precisely which risks you need to tackle, and just as importantly, which ones you don’t.
Being explicit about your risks also allows your team to act as a cohesive unit.
What happens when you don’t identify risks?
Building a system without a firm grasp on risks is a little like playing football in a thick fog; no one has any idea where their teammates are (or the ball, for that matter). There’s no cohesion. No common vision. Just confusion.
It may seem harsh, but you’ve probably been on a team like this yourself at some point in your career. More often than not this lack of communication manifests itself in things like 80% completed features or “tangents” struck off on. These issues are fundamentally miscommunications that could have been avoided with a little up-front clarity.
Discovering Risks
To suss out your most pertinent risks, spend some time brainstorming and rating risks for the task at hand. Start with risks inherent to your domain or approach–your prototypical risks–then branch out into more fanciful failure scenarios. As you go, take the temperature of each scenario in the form of a high (H), medium (M) or low (L) rating. Remember, risk is not just the likelihood something will go wrong, but the product of that probability and the severity if it were to occur.
If you’re especially fresh you may be thinking you have little insight to offer because you haven’t experienced many failures yet. That couldn’t be farther from the truth. Identifying risks is all about being imaginatively pessimistic, and you’ve got that blissful child-like naivety on your side. Sure, with a broad body of failure behind you you’ll have an easy time picking out the most obvious risks. That kind of experience can also make folks myopic, though. The most insidious risks can only be discovered via creativity.
As you start to run out of steam, start to explore deeper aspects of the project or feature; what features does it have? What qualities must it embody? How might it fail in conjunction with other parts of the system? Consider also assumed risks. Are there risks on the project everyone has obviously already considered? Think again. Never attribute to intent what could just as easily be attributed to ignorance.
You’ll know you’re done identifying risks when it starts to feel like there’s been a weight lifted from your chest. If we just mitigated these risks then everything will be OK. Conversely, you might feel overwhelmed. This should be a clue that you’re not quite done yet. If others feel the same way, then you should definitely consider spending a bit more time on architecture and design. That is the point of risk-driven architecture, after all; to identify and mitigate risk until a comfortable level.
Describing Risks
Once you’ve identified a rough set of risks, the next thing to do is describe them. Rather than defining a risk in loose terms, it’s best to define them as clearly testable scenarios. For example, instead of saying it is a risk that “the site is too slow to use,” you might state it a risk that “User’s experience page loads greater than 2000ms during peak load.”
By crafting testable failure scenarios, it it becomes possible to validate your application meets expectations in an automated fashion. Even the process of eliciting such objective statements is valuable; it forces stakeholders and developers to explore and define behavior on common ground.
See my post Make Measurable Statements for more information on, well, making measurable statements.