Hacker News new | ask | show | jobs
by jacques_chester 2297 days ago
The relevant book for this is Measuring and Managing Information Risk: A FAIR Approach by Freund and Jones[0].

Both books are worth reading; Hubbard's influence on FAIR is noticeable and positive. FAIR has the advantage that it comes with a fairly built-out ontology for assembling data or estimates. The OP touches on the top level (Loss Event Magnitude and Loss Event Frequency), but the ontology goes quite deep and can be used at multiple levels of detail.

The calculations are not difficult, I've implemented them twice in proofs-of-concept, including one that produces pretty charts.

The difficult part, to be honest, is that developing good estimates is difficult and frequently uncomfortable and the gains are not easily internalised.

Additionally, serious tool support is lacking in the places where it would make a difference -- issue trackers, for example.

[0] https://www.amazon.com/Measuring-Managing-Information-Risk-A...

edit -- Another good book in this area is Waltzing with Bears by DeMarco & Lister. A short, funny, insightful read, as you'd expect from the authors of PeopleWare: https://www.amazon.com/Waltzing-Bears-Managing-Software-Proj...

1 comments

I regularly put a risk / loss / impact assessment into my issue tracker tickets - it's not the tool support is not there, it's that

a) everyone else needs to do this across the board

b) it's still just a guess - normalising my guess and you're guess is hard

b) it's still just a guess - normalising my guess and you're guess is hard

True, but that's where the calibrated probability assessment stuff comes in. If you can at least establish obviously correct (if very course grained) upper and lower bounds for estimates and then gradually shrink them in until you aren't confident doing so anymore, you have something at least slightly better than a complete guess. And if you can choose the correct distribution that the actual values would vary over, then you can use Hubbard's approach using a Monte Carlo simulation, and get some insight into likely outcomes.

No, it's not a perfect approach, but it gives you a little something to hang your hat on.

Tool support would ideally both of those problems easier. But good estimating is in itself fundamentally a "system 2" activity.
system 2: is that a reference to 'no silver bullet'?
I assume it's a reference to Kahneman's "Thinking, Fast and Slow".
Thanks