Well, as someone said, because it’s the worst of social media, combined with the worst of corporate culture and the worst of website design. Because dealing with it regularly is as interesting as cleaning out my sock draw, and because the tone, like an endless ritalin fuelled rotary meeting, is just plain unhealthy. The philosopher Kant once said that you should always treat human beings as ends in themselves, and never as just the means to an end. Well LinkedIn for crimes against the categorical imperative alone you have to go…
Archives For Humour
A Trump presidency in the wings who’d have thought! And what a total shock it was to all those pollsters, commentators and apparatchiks who are now trying to explain why they got it so wrong. All of which is a textbook example of what students of risk theory call a Black Swan event. Continue Reading…
More infernal statistics
Well, here we are again. Given recent developments in the infernal region it seems like a good time for another post. Have you ever, dear reader, been faced with the problem of how to achieve an unachievable safety target? Well worry no longer! Herewith is Screwtape’s patented man based mitigation medicine.
The first thing we do is introduce the concept of ‘mitigation’, ah what a beautiful word that is. You see it’s saying that it’s OK that your system doesn’t meet its safety target, because you can claim credit for the action of an external mitigator in the environment. Probability wise if the probability of an accident is P_a then P_a equals the product of your systems failure probability P_s and. the probability that some external mitigation also fails P_m or P_a = P_s X P_m.
So let’s use operator intervention as our mitigator, lovely and vague. But how to come up with a low enough P_m? Easy, we just look at the accident rate that has occurred for this or a like system and assume that these were due to operator mitigation being unsuccessful. Voila, we get our really small numbers.
Now, an alert reader might point out that this is totally bogus and that P_m is actually the likelihood of operator failure when the system fails. Operators failing, as those pestilential authors of the WASH1400 study have pointed out, is actually quite likely. But I say, if your customer is so observant and on the ball then clearly you are not doing your job right. Try harder or I may eat your soul, yum yum.
Well hello there, it’s been a while hasn’t it?
In the absence of our good host I thought I’d just pop in and offer some advice on how to use statistics for requirements compliance. Now of course what I mean by requirements compliance is that ticklish situation where the customer has you over the proverbial barrel with an eye-gouger of a requirement. What to do, what to do. Well dear reader all is not lost, what one can do is subtly rework the requirement right in front of the customer without them even recognising it…
No! I hear you say, ‘how can this wonder be achieved Screwtape?’
Well it’s really quite simple, when one understands that requirements are to a greater or lesser extent ‘operationally’ defined by their method of verification. That means that just as requirements belong to the customer so too should the method one uses to demonstrate that you’ve met them. Now if you’re in luck the customer doesn’t realise this, so you propose adopting a statistical proof of compliance, throw in some weaselling about process variability, based on the median of a sample of tests. Using the median is important as it’s more resistant to outlier values, which is what we want to obfuscate (obviously). As the method of verification defines the requirement all of a sudden you’ve taken the customer’s deterministic requirement and turned it into a weaker probabilistic one. Even better you now have psychological control over half of the requirement, ah the beauty of psychological framing effects.
Now if you’ll excuse me all this talk of statistics has reminded me that I have some souls to reap over at the Australian Bureau of Statistics*.Mmm, those statisticians, their souls are so dry and filled with tannin, just like a fine pinot noir.
Till the next time. Yours infernally,
*Downstairs senior management were not amused by having to fill out their name and then having a census checker turn up on their doorstep asking whether they were having a lend of the ABS.
Earlier this year the US Government declassified a WWII OSS field manual on sabotage. Now the Simple Sabotage Field Manual is not what you might think. No it’s not a 101 on blowing up bridges, nor is it a cookbook for how to conduct Operation Kutschera, but rather it’s aimed at a lower key sabotage of ordinary working practices inside the organisation. For example using conferences and meetings to strategically delay decision making. Nobody get kills but that new Panzer design with the Porsche turret? Well sorry Reichs Marshall it’ll be buried in design committee until about 1948. Charlie Stross went on to twitter asking for modern updates to the OSS manual, I’m not sure whether that exercise increased or decreased the net sum of human happiness, but hey, it was amusing.
Which got me to thinking, if you read the OSS manual and find that every working day seems like a text book play courtesy of the boys from Prince William Park, then shouldn’t you logically conclude that you are sitting in the middle of a war? If you see folk in your organisation regularly using moves out of the OSS play book they may not be just haplessly incompetent. If nothing else this should make you look at your daily fare of corporate hooey in a new light. So stay frosty people, and remember three times is enemy action.
The 15 commandments of the god of the machine
Herewith, are the 15 commandments for thine safety critical software as spoken by the machine god unto his prophet Kopetz.
- Thou shalt regard the system safety case as thy tabernacle of safety and derive thine critical software failure modes and requirements from it.
- Thou shalt adopt a fundamentally safe architecture and define thy fault tolerance hypothesis as part of this. Even unto the definition of fault containment regions, their modes of failure and likelihood.
- Thine fault tolerance shall include start-up operating and shutdown states
- Thine system shall be partitioned to ‘divide and conquer’ the design. Yea such partitioning shall include the precise specification of component interfaces by time and value such that all manner of men shall comprehend them
- Thine project team shall develop a consistent model of time and state for even unto the concept of states and fault recovery by voting is the definition of time important.
- Yea even though thou hast selected a safety architecture pleasing to the lord, yet it is but a house built upon the sand, if no ‘programming in the small’ error detection and fault recovery is provided.
- Thou shall ensure that errors are contained and do not propagate through the system for a error idly propagated to a service interface is displeasing to the lord god of safety and invalidates your righteous claims of independence.
- Thou shall ensure independent channels and components do not have common mode failures for it is said that homogenous redundant channels protect only from random hardware failures neither from the common external cause such as EMI or power loss, nor from the common software design fault.
- Thine voting software shall follow the self-confidence principle for it is said that if the self-confidence principle is observed then a correct FCR will always make the correct decision under the assumption of a single faulty FCR, and only a faulty FCR will make false decisions.
- Thou shall hide and separate thy fault-tolerance mechanisms so that they do not introduce fear, doubt and further design errors unto the developers of the application code.
- Thou shall design your system for diagnosis for it is said that even a righteously designed fault tolerant system my hide such faults from view whereas thy systems maintainers must replace the affected LRU.
- Thine interfaces shall be helpful and forgive the operator his errors neither shall thine system dump the problem in the operators lap without prior warning of impending doom.
- Thine software shall record every single anomaly for your lord god requires that every anomaly observed during operation must be investigated until a root cause is defined
- Though shall mitigate further hazards introduced by your design decisions for better it is that you not program in C++ yet still is it righteous to prevent the dangling of thine pointers and memory leaks
- Though shall develop a consistent fault recovery strategy such that even in the face of violations of your fault hypothesis thine system shall restart and never give up.