Today we are faced with a challenge of similar magnitude.  The mathematical concepts underlying sophisticated algorithms implemented in software are not, in most cases, new.  But, the computing power available to take advantage of these tools is.  As observed earlier in this book, one common human frailty is an inability to truly grasp the implications and meanings of large numbers.  When someone says that a processor has over two billion transistors, we typically lack any real comprehension of what that means.  And, if one points out that if the advertised transistor count is that high, that in reality there are at least double that number of actual transistors in the chip because chips are designed to self-heal as individual components fail, and that transistors are actually only one of a half dozen or more integrated circuit component types on the chip, thus making the actual IC component count for such a chip is well above 5 billion …. most humans have no real way of understanding what all of that means.

 

In just the past five years or so, and because of all of those transistors and other IC components, software has become powerful well beyond the ability of most people to appreciate, including most engineers who wield that power.  Some of the results of this untamed genie being out of its bottle have begun to be experienced. 

 

Privacy for most people has in many ways ceased to exist.  The ability to distort and mislead how large portions of the population perceive reality has become readily available to any bad actor who is so inclined to use such tools.  The tools to create seemingly real video of anyone saying and doing almost anything are available to anyone determined to get their hands on them. 

 

One of the most dangerous results of all of this software power having been unleashed, is that engineers are now using it for things that they should not.   In effect, many engineering communities have become addicted to using software to solve problems and implement designs that should be solved or implemented using very different underlying hardware concepts.  Doing it in software has become so easy, that good systems hardware design principles are routinely being ignored. 

 

Products that have software performance issues to the point of causing tragic accidents and deaths have become all too common.  Typically, in such cases it is not solely the quality of the software that is the problem.  Yet, in almost every case where these issues have arisen, software quality is precisely the thing that has been blamed.  This is unfortunate.  The problem is that as often as not, software-only solutions have been used as a cost savings over proper hardware design. 

 

Software power should almost never be substituted for proper hardware design.  This practice can be dangerous in the extreme, and yet it is becoming ever more common.  Currently, few engineers afflicted with this perceptual disease are cognizant of the risks they are running, or even that they have adopted this bad behavior.  It is a perceptual problem not unlike those that alcoholics have toward taking another drink, or that drug addicts have toward taking another pill, or shooting up just one more time. 

 

Just as the first generation of nuclear reactor engineers seemed to be incapable of recognizing the foolishness and serious harm for others that they were creating with the things they built, it is clear to me that many engineers currently have virtually no appreciation of the misplaced hubris inherent in many of the things they are designing using software. 

 

For legal reasons, I will not cite specific examples.  However, it is not necessary that I do so.  Anyone who reads this can quickly rattle off the identities of several catastrophes or monstrous product performance failures that have been blamed on software quality, and which qualified commentators have observed should not have been built the way they were in the first place. 

 

Human problems of perception associated with destructive behaviors are classed by clinical psychologists as diseases.  Most such diseases present themselves with a fairly wide degree of seriousness based upon the extent to which a patient is both engaged in the destructive behavior, their risk of causing harm to themselves or others, and the extent to which they are in denial.  Thus, many such diseases have been classed as some type of “spectrum disorder.”

 

The use of software tools for things which they should not be used, and which result in either real or significant risk of real harm to others is a disease and properly classified as a spectrum disorder. 

 

People who work in IT need to urgently develop a sensitivity to the existence of this disease and learn to identify it when it presents itself.  When an instance of the disease is identified, appropriate intervention measures should be brought to bear.