Engineers: Stop using these terms…
Although I’ve only been an engineer for a short time compared to many of my colleagues in the Defense and Transportation sectors, I’ve been around long enough to hear a couple terms over and over again that need to stopped being used for several reasons. 1.) They don’t have a formal definition. If a term can’t be defined, then it shouldn’t be used. 2.) They cause more confusion. They were meant to help define new ideas or concepts, but in reality, have complicated what engineers are talking about. 3.) The public has no idea what we’re talking about. When we use some of these terms in public, we sound crazy and this is why many people have trouble with engineers and getting interested in technological fields. Without further a do, the terms that need to die and alternatives that should be used instead:
System-of-Systems: I could write a whole article on this term alone, but I’ll keep this brief. Merriam-Webster describes a system as “a group of interacting or interrelated entities that form a unified whole”. Perhaps even more enlightening is the second sentence to clarify the term: “A system, surrounded and influenced by its environment, is described by its boundaries, structure and purpose and expressed in its functioning”. The keyword is boundaries. A system is described by its boundaries. In other words, when we say system-of-systems, my immediate question is how many boundaries are there? You could draw boundaries around 10, 100, or 1,000 different systems within the system, and the boundary for the system may (and usually does) conflict with the systems that it is supposed to encompass.
Alternative: Just call something a system. That way people only need to understand the one boundary without having to figure out what systems exist within the system. You can always widen the system boundary to create new systems without calling it a system-of-systems. Using the term “subsystem” to refer to components within the system is great too. As long as the system boundary is clear, one can identify the subsystem components within that system.
Fail-safe system: This one sounds good at first but has serious implications given how accidents occur with software-intensive systems. Most accidents that occur nowadays are not necessarily the result of hardware failures or software crashes. Most of them are the result of complex interactions that occur between humans and software. There are hundreds of examples across numerous industries, but the point is that the term “fail-safe” does not necessarily account for these types of accidents. In other words, when we say something is fail-safe, it implies that the system is completely safe when the term actually means that it is only designed to remain safe in the event of a failure. However, if there is no failure but an accident still occurs, then what?
Alternative: Again, just use system. Engineers design systems to be safe regardless of whether a failure occurs or not. We don’t want the public thinking otherwise. Saying fail-safe system or even safe system implies that we are trying to convince people that a system is safe. Additionally, fail-safe mechanisms can often be the cause of accidents due to the complex interactions. We definitely don’t want to be misleading the public, so once again, just calling something a system or a safe system is best.
Root Cause: A Root cause analysis (RCA) is a systematic process for identifying “root causes” of problems or events and an approach for responding to them. The problem with the term “root cause” is determining whether something is actually a cause or if it is simply contributing to the problem. Many times, there are issues that can contribute to an accident without necessarily “causing” the accident to happen. Determining the causation of an event is extremely difficult; the strong correlation to an event is not the same as the causation of that event.
Alternative: Factor or Contributing Factor. I prefer the term “factor” because it implies that something was involved in the event without necessarily causing it to happen. One may also add the word contributing to indicate that the factor contributed to an event.
This is all my personal opinion but let me know what you think. Thoughts are heavily inspired by Nancy Leveson and the MIT Systems Engineering Research Laboratory.
