Behaviours, engineering, History, science, statistics, STEM

PPFF #162: bias – another one

Good morning,

I work in engineering. By now most of you know that. In fact a lot of people I came to know in the past few years are unfortunately from this field. I say ‘unfortunate’ for a good reason, not to be humorous but because people are made redundant on a regular basis in engineering. Where I work in particular, I’ve seen the number of workers go from circa 1000 to 250 in the space of less than 3 years. Indeed this is what preoccupied much of my mind this week; the impending ax to be sharpened and to be deployed, the direction of its swing, the amplitude of its oscillation, the dampening effect on the oscillation etc., to stretch the metaphor. So I wondered ‘why’ naturally, and after a number of discussions with colleagues, we all agreed that it was because of outsourcing of work to those so-called ‘high value centres’, the decline of the specific industry we work in, automation and the cyclical nature of the market we depend on etc. As true and obvious as that sounds, I wondered further, if there was more to the quagmire in which we currently find ourselves, than the immediately obvious reasons that brought us to that conclusion.

Then this week, I had a pleasant chance encounter with the concept of ‘survivorship bias’. It’s an easy enough concept to understand – whatever data we have, we have (easy access to) them because something survived or succeeded. For those that either didn’t survive or didn’t quite succeed, either we have no access to their data or they are ignored. The example that best illustrates this point is the study conducted by the ‘famous’ Hungarian/American statistician Abraham Wald, the ultimate aim of which was to minimise aircraft losses to anti-aircraft attacks. The available data-set for this study was from the aircraft that had returned from missions, and survived the damages like in the image below (not mine).

Credit: McGeddon

The obvious recommendation for reinforcement/extra armour would have been for the damaged areas. However, Wald, being quite a clever chap, reasoned that since the returned aircraft had survived despite the damages, there would be no good reason to provide extra armour in those areas. Inversely in the absence of any data from the aircraft that had not survived and never returned, it would make more sense to take chances with providing extra armour in the areas with no or little damage in the surviving aircraft as it was more reasonable to assume that those were the areas of damage that might have caused them to crash. The damages in the returning aircraft represented areas where a bomber could take a hit and still survive. Wald therefore made his recommendations based on this reasoning.

Back to my original engineering/redundancy problem. I agree that outsourcing and decline in the industry are two of the few reasons why there are so many redundancies in (construction-related) engineering as well as the fluctuating nature of the market. But it is also possible that back in the days of our parents’ generation, in the post-war economy, engineers were scarce and that engineering was one of the most stable and abundant work categories to be employed in. Having spotted those opportunities (readily available data) at the time, perhaps they promoted this line of work and encouraged the following generation to be engaged in this sector. Alas, with no access to the missing data set (i.e. future) they had perhaps fallen victim to the ‘survivorship bias’ and made the matters worse by over-crowding the engineering employment market with their ill-thought-through albeit well-intended encouragement.

All this is just a conjecture with inconsistent logical fallacies but worth a thought or two especially when it comes to recommending choices for the future based on the current reality and situations. In my opinion, there’s too much emphasis on STEM subjects at the moment especially in computer-related STEM subjects. You watch this space. In 20 years time, there could be overcrowding of coders and programmers. In any case, whatever you do, remember, all the data available to you isn’t all the data there is.

Have a fully comprehensive Friday; take Saturday and Sunday into account if you need to.