“De-risking is the art of reducing risk with the code that you deploy. What all steps can you take to reduce the risk of disaster?” Honestly, I talk about der

“De-risking is the art of reducing risk with the code that you deploy. What all steps can you take to reduce the risk of disaster?” Honestly, I talk about derisking most in two contexts in our projects: schedule, invention. Normally this means that derisking is about frontloading unknowns and finding pivot decisions that reduce the likelihood of getting too far in the wrong direction or accumulating too much uncertainty. I don’t use “risk” too often when talking about fault tolerant code or system design. If you’re taking on “risk” in code, like the chance of a lost message, a race condition, or corrupted data, I’m going to take away the keys. Note: I encounter shoddy “we can go hours without a crash, so it’s good” work more than I’d like to admit. It is possible to know why code and systems fail (and account for it) much more than has become industry norm these days.