Going out on a limb I'd say that debugging is a skill that's learned in practice, not taught, so if it was as easy to "debug" the human body as it is to debug a computer program, why would computer programmers be better at debugging in their domain then doctors are in theirs? Surely doctors would have varying degrees of skill in this regard, but so do programmers, and it's likely that a) "good" doctors would count this "debugging" as one of their most important skills and b) that Robin Williams had really good doctors.
These factors seem to make diagnostic medicine quite challenging:
* It's often impossible to gather the information you need to make a certain diagnosis without an endless series of tests that may be prohibitively expensive or dangerous to the patient's health themselves.
* Feedback to attempts to "probe" the problem e.g. trying a course of a certain medication may be very difficult to interpret because of delayed reaction, individually unique responses, and/or other external factors that make it difficult to attribute some observed effect to cause X.
* The patient is not getting any younger this whole time, and may become impatient with the process and accept an imperfect solution or simply not have enough time due to the progress of their illness for all avenues to be explored.
* Patients may deliberately hide some of their symptoms, e.g. the article's author's theory that her husband was keeping hallucinations secret.
We get to mess with large permutations of different causes and effects, that we stimulate, in a short time while that would be unethical for medical professionals.
I get anxious every time I have to debug live systems. Developers are lucky because we can reproduce and test fixes on non-live systems. As a bonus, we can step through the code at critical junctures and can examine the complete state of the system
I always liken it to being a detective trying to piece together a crime scene from incomplete clues. But now that I think about it, it's also quite a lot like trying to diagnose an illness from symptoms.
I had about 2-4 systems talking to each other for this project (that's counting the system that I wrote that works as a plugin/module loader and all of it's plugins as 1 system).
It's a relic from my past that I'm glad I left behind. Editing plugins live, writing everything in usually the one or two days of free time I had between school engagements, and a few other tricky things that happened, this was probably one of the most funny projects I worked on.
By the end of it, I had two config file formats for pretty much everything, I opted out of using the right tool for the job most cases, and I kept having to upgrade hardware which was a pain in the ass since I didn't have any setup instructions since I made the damned thing.
Following is a list of everything that's public.
https://github.com/gravypod/StarmadeWrapper
https://github.com/gravypod/StarmadeWrapper-API
https://github.com/gravypod/StarmadeDebugging
https://github.com/gravypod/Checkers
https://github.com/gravypod/Starmade-Log-Reader
https://github.com/gravypod/StarmadeWapper-Panel
https://github.com/gravypod/StarmadeWrapper-Claim
https://github.com/gravypod/StarmadeWrapper-Warps
https://github.com/gravypod/Starmade-Map
It was quite a bit of a mess and I can definetly agree, debugging live systems, debugging distributed systems, and debugging unverified/untested/undocumented systems is crap too.
I'm pretty sure that being a doctor is the same as this except thousands of times worse. The amount of times I've messed up when working on my spaghetti plate was more then I can count and I'm pretty sure the human body is more slopily put together then my leaning tower of crap.
It's a complete mess of spaghetti code where anything that happens is the result of dozens of sub-systems trying to invoke or override each other.
The problem is that programmers can make a hypothesis and then test while doctors can't.
Doctor's are effectively engaging in "shotgun debugging" because they don't have good "this cause to this effect" for a lot of systems. The drugs they have to effectively "unit test" don't have narrow effects, so those add extra uncertainty.
They're getting better. And I wish the "deep learning" people would target this much harder--it's almost an ideal candidate (we have these symptoms--we ran these tests--give us a probability list of the top 5 things we should be ruling out next). However, getting the data seems to be the problem.
If you have a live system bringing in millions of dollars everyday but it hangs every once in a while, do you reboot it, or attach a debugger to it while it's hung?
What your describing sounds a lot like team debugging and trouble shooting! Trial and error of a failed hypothesis, further testing when someone looks at the data with fresh eyes. Finally a solution, or in your case, clarity.
What is necessary is to force the medical community to build up better tools for medical diagnostics and the storage and exchange of patient health information.
Answering the criticism raised in several responses, it's not that a deep and systemic understanding is specific to software, and inapplicable elsewhere. Yes, the fact of a human-constructed system may make the intention of a system clearer, and its detection easier, but the entirety of existance, at least as our brains are fundamentally equipped to make sense of it, is a system. Primary phenomena are rooted in underlying systems, prerequisites, causes, and interactions. "Five whys", or any other set of inductive explorations, is not a privilege of software systems and workers alone.
The asystematic approach is one that is, paradoxically, a result of increasing complexity of knowledge itself. Rather than individuals spanning multiple disciplines or even subdisciplines or specialties, they're are trailed off into individual leaf-nodes of research, skill, and application, and efforts to break out of this pigeon hole are obstructed at virtually all levels of the system.
Pay and reward are largely commensurate with specialisation. Reputation is contingent on specialisation. Procedure compensation is contingent on specialisation. Access to diagnostic equipment is contingent on specialisation.
And so forth.
Each individual member associated with treatment has their own very small aspect as their particular area of concern.
In software, it's like the person who resolves a bug in medical pricing codes by simply applying the value that was expected in that specific instance for a price, rather than, say, fixing an algorithm or lookup table such that the right answer appears regardless of specific circumstances (I'm paraphrasing from an actual bug/fix story seen recently). From the point of view of a naive management system, that worker has a very high bug resolution rate -- but they're treating the symptom only of an underlying software deficiency.
In a similar vein: you can "fix" a water spot on a wall by repainting the wall.
Or you could replace the plaster that's been waterlogged.
Or you could seal the exterior wall leak that's allowing water in.
Or you could shore up the foundation that's settled, allowing the wall to leak.
Or you could address the underlying geology -- a sinkhole, ground subsidence, a fault line -- that's causing the foundation to move.
Paint is cheaper than plaster is cheaper than siding is cheaper than concrete is cheaper than earth-moving equipment. And there may be an appropriate level of fix. But walking through the problem to its fundamental source(s) provides a full understanding of the problem.