"Treating the symptom, not the disease."

2025-03-04 13:29 by Ian

This phrase meant something in the past, but is now more commonly employed as a thought-terminating cliche.

Minor technical gripe before beginning: Signs and symptoms are separate things. A "sign" is a fact observable by others. A "symptom" is a claim of suffering that can't be observed. Nausea is a symptom. Vomiting is a sign.

Frequently, a patient's own healing response is the proximate cause of death. Not the underlying cause. If you have a guy with a 107-degree fever, you'd better put him on ice before his own febrile response turns him into a brain-damaged vegetable (or kills him outright).

Although fever is a sign, it should drive home the point that sometimes, treating the consequences of a problem (rather than the problem itself) is absolutely the correct course of action. Allergic reactions and cytokine storms are other examples. People carry epinephrine pens for a reason that has nothing to do with allergens.

Sometimes, you treat a symptom as part of a diagnostic tree when signs are absent or ambiguous. That is, sometimes a symptom is the only fulcrum you have to figure out what's really going wrong.
"Take this niacin tablet. Did your headache go away? No? Well you are as red as a boiled lobster, so that rules out cardiovascular hypertension."

So the complaint isn't really about treating symptoms. It's about lazy clinicians (and patients) that stop diagnosing when the problem goes away. The patient isn't devoid of blame, here.

This exact same psychology applies to engineering as well as it does medicine. For software engineers, a "symptom" is an intermittent problem that defies reproduction under test conditions. Depending on circumstances, the same flavor of surface-level guesswork about the ultimate cause is your only realistic option for gaining enough knowledge to fix the problem. Likewise, if the problem is severe enough, you may be forced into "putting the problem on ice" by treating the consequences to avoid the machine turning itself into a smoking pile of slag before you can understand and fix the root cause.

Medical doctors have a worse set of epistemological constraints vis-a-vis software engineers. Our chains of cause-and-effect are almost always well-documented, whereas doctors need to operate in an unresolvable fog of knowledge. There will always be unknown biochemical pathways and interactions in a biological system. Moreover, a biological system never stays static (unless it dies), whereas a software engineer (almost) always has an option of "stopping the clock" (literally) to examine the state of a system with perfect clarity. There is thus no reason for a software engineer to cease root-cause analysis before its completion.

Iatrogenic death is a problem, too. Most software practitioners have never faced a world in which they can permanently wreck a machine with code. Embedded engineers, however, face it regularly.
If you screw up the OTA update, the "patient" enters a permanent coma.
If you don't switch off the motor power before your blocking diagnostic dump begins, the patient might rip itself apart.
If you fail to throttle the CPU while waiting for DMA to complete, you might induce a condition analogous to metabolic acidosis, and drain your batteries at double the intended design limits, thereby starting a battery fire.

The point of all of this analogy is that many of us (especially in embedded) need to operate on best-practices and humility that is comparable to a medical ideal.

Previous:
Next: