The Cause in 'Cause and Effect' - Troubleshooting with Psychology

The Cause in 'Cause and Effect' - Troubleshooting with Psychology

By Tom Carpenter On 01/12/2022 - Add Comment

In this article, Tom Carpenter briefly defines some psychological principles impacting the troubleshooting process for wireless engineers.

As a wireless troubleshooter, determining cause in a problem scenario is important. Something has generated the effect seen and that thing is the cause. But, given the many possible causes, how does one determine the actual cause in a given scenario? It typically starts, based on expertise, with the determination of the most likely causes. The process uses discounting as defined by Harold H. Kelley (1972) in Causal Schemata and the Attribution Process and The Process of Causal Attribution (1973). The discounting principle states that, "The role of a given cause in producing a given effect is discounted if other plausible causes are also present. (Kelley, 1973)" Stated plainly, the more "causes" you are aware of and the more familiar you are with the problem (the system context and configuration variables in a wireless solution), the more likely you are to discount many causes and augment others. This is the core of expertise. Through knowledge and experience you discover the likely causes of various problems (effects) and therefore implement rapid cause discounting.

For example, if you've faced the same problem many times and most of the time it is caused by the same issue, you will discount other causes based on this experience - and you will be right most of the time. An expert intuitively discounts unlikely causes. A novice becomes an expert by learning as much as possible about the target system/concept and gaining experience with it, which results in a large database of potential causes of effects. These causes can then be evaluated through discounting (less likely or less impacting) and augmenting (more likely or more impacting) to determine the likely issue in a given situation.

Kelley further advanced the psychological theory of attribution when addressing how people determine the cause of other people's behaviors. He suggested, in his model of attribution theory, that people behave as they do for three reasons (causes): the persons themselves, the stimulus or entity acting on them, or the circumstances surrounding the occurrence at that time. To relate this to causal analysis in wireless solution troubleshooting, we can state that there are three causal categories: the system itself (some internal error, failure, or configuration problem), the input to the system (the frames are malformed, for example), or the environment at the time (sporadic interference, for example). Let's consider an example of each:

• An AP is experiencing heat problems causing intermittent failure (the system itself).
• A client is sending frames to the AP with bits set incorrectly disallowing connection or communication (the input to the system).
• A machine generates RF energy when it is active causing interference (the environment at the time).

Each of these represents real-world problems wireless troubleshooters face and I'm sure you can come up with dozens more in each category. Developing lists of causes and effects builds an information base that you can use in the troubleshooting process. In fact, Kelley, in a 1980 paper (Attribution Theory and Research) suggests a model that is based on antecedents, attributions, and consequences:

• Antecedents
• Information
• Beliefs
• Motivation
• Attributions
• Perceived Causes
• Consequences
• Behavior
• Affect
• Expectancy

That is, your information base, beliefs, and motivations inform your perceived causes and result in particular actions. Therefore, if the foundation is wrong or weak (little information, wrong beliefs, weak motivation), you are less likely to arrive at the proper cause(s) and take the proper action(s).

Based on the information presented here as a starting point for considering the psychology of troubleshooting, you can see that the development of a list of common causes to common problems can be quite beneficial. It is for this reason that I have always been a proponent of documentation. When we document the effect (the problem) and the cause, after resolving an issue, we build such a list. Such documentation can be internal or external. For example, many wireless engineers document important findings in public blogs, which helps to forward the knowledge to the entire community. Sensitive information, such as configuration parameters used within an organization, should not be shared in the public space; however, principles and concepts are valuable to all.

So here we are, at the end, and once again I'm suggesting the need for documentation. Hopefully we hear it.

Tagged with: troubleshooting, wireless

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.