Comment by jacquesm 3 days ago
If you haven't done so: please write a book. Aim it towards software professionals in non-regulated industries. I promise to buy 50 to give to all of my software developing colleagues.
As for 'N', for turboprops it is 45, for jets it is 30.
Just started reading the linked text after reading your comment and I agree, this is high quality education, and enjoyable. It's an art, really. Thank you for sharing your work and please keep it up.
Just a thought I had while reading your introduction: this is applicable even to running a successful business model. I'm honestly having trouble even putting it into words, but you have my analytical mind going now at a very late hour... Thanks!
Ok. I am impressed with your ability to take such complex subjects and make them plain, you are delivering very high quality here. The subject is absolutely underserved in the industry as far as I'm aware of it, and I would love to have a book that I can hand out to people working on software in critical infrastructure and life sciences that gets them up to speed. The annoying thing is that software skills are values much higher than the ability to accurate model the risks because that is only seen as a function of small choices standing by themselves. A larger, overall approach is what is very often called for and it would help to have a tool in hand to both make that case and to give the counterparty the vocabulary and the required understanding of the subject in order to have a meaningful conversation.
Edit: please post your link from above as a separate submission.
Your writing is good, please keep at it. I think it would help a lot if you made it clearer when you're talking between root-cause-analysis for software, aviation, other things, or generically.
Also, your train-of-thought is pretty deep; bulleting runs out of steam and gets visually confusing, especially with the article table-of-contents on RHS, you're only using <50% of screen width. Suggest you need numbered/lettered lists and section headings and use the full screen width.
See also: various points in the Evil Overlord list[0]. Selected examples:
#12: One of my advisors will be an average five-year-old child. Any flaws in my plan that he is able to spot will be corrected before implementation.
#60: My five-year-old child advisor will also be asked to decipher any code I am thinking of using. If he breaks the code in under 30 seconds, it will not be used. Note: this also applies to passwords.
#74: When I create a multimedia presentation of my plan designed so that my five-year-old advisor can easily understand the details, I will not label the disk "Project Overlord" and leave it lying on top of my desk.
Seconded.
That being said: I have - for some years now - started to read air accident board reports (depending on your locale, they may be named slightly different). They make for a fascinating read, and they have made me approach debugging and postmortems in a more structured, more holistic way. They should be freely available on your transportation safety board websites (NTSB in America, BFU in Germany, ...)
Google’s SRE STPA starts with a similar model. I haven’t read the external document, but my team went through this process internally and we considered the hazardous states and environmental triggers.
https://sre.google/stpa/teaching
Disclaimer: currently employed by Google, this message is not sponsored.
Also check out risks digest:
I want to write more about this, but it has been a really difficult subject to structure. I gave up halfway through this article, for example, and never published it – I didn't even get around to editing it, so it's mostly bad stream of consciousness stuff: https://entropicthoughts.com/root-cause-analysis-youre-doing...
I intend to come back to it some day, but I do not think that day is today.