Inescapable Legacy

We click and tap our way through life near-seamlessly. Gone are the days when you had only a keyboard to interface with your desktop computer’s software; when you had to type at a DOS prompt to navigate between folders with a cd\ command or check the properties of your 5.25 floppy with chkdsk a: [if you are under 25-30 years-of-age and curious, you can still emulate the OS shell here and (BTW) this is what a 1.2 MB, 5.25 floppy looked like]. Technology has developed quickly with one advancement built on another, built on another. Our computing power is stronger than ever, yet is simultaneously even more frail.

… all computers are reliably this bad: the ones in hospitals and governments and banks, the ones in your phone, the ones that control light switches and smart meters and air traffic control systems. Industrial computers that maintain infrastructure and manufacturing are even worse. I don’t know all the details, but those who do are the most alcoholic and nihilistic people in computer security.

The quoted passage above is from an article titled , “Everything Is Broken” by Quinn Norton. It is a very interesting and sober read about how vulnerable everyone is to being hacked or exposed through their digital devices. She writes:

… every time you get a security update, whatever is getting updated has been broken, lying there vulnerable, for who-knows-how-long. Sometimes days, sometimes years. Nobody really advertises that part of updates. People say “You should apply this, it’s a critical patch!” and leave off the “…because the developers fucked up so badly your children’s identities are probably being sold to the Estonian Mafia by smack addicted script kiddies right now.”

The hardware on our devices continues to improve, but the software continues to be a house of cards. How is it that our most modern and up-to-date devices continue to have holes and gaps in security? One reason is legacy code.

Legacy code is source code that is inherited from someone else or from an older version of the software. To put it simply, that brand-new super-fast Windows 10 convertible laptop with an ultra-HD display, SSHD, 16 gig of RAM, and a quad-core processor is still running on a lot of code that was written in the late-1980s for Windows 3. That new Pixel smartphone with Android Nougat 7.0 is still running on code that was written for Android Froyo 2.2 in 2010, which was built on a Linux kernel that is even older.

Long story short, as a greater demand is placed on software to have more and more functionality, software engineers continue to build more new code on top of old. This new code is produced quickly. Cheaply. Haphazardly. Per Zeynep Tufekci:

A lot of software is now old enough to be multi-layered. Airline reservation systems are particularly glitchy since they’ve been around a while. I wouldn’t be surprised if there is some mainframe code from the 1960s still running part of that beast. In the nineties, I paid for parts of my college education by making such old software work on newer machines. Sometimes, I was handed a database, and some executable (compiled) code that nobody had the source code for. The mystery code did some things to the database. Now more things needed to be done … So I wrote more code that intervened between the old programs and the old database, and added some options that the management wanted.

To the lay-person, this may seem like a reasonable solution at first glance, but you would be mistaken. You see…

It was a lousy fix … Think of it as needing more space in your house, so you decide you want to build a second story. But the house was never built right to begin with, with no proper architectural planning, and you don’t really know which are the weight-bearing walls. You make your best guess, go up a floor and… cross your fingers. And then you do it again. That is how a lot of our older software systems that control crucial parts of infrastructure are run. This works for a while, but every new layer adds more vulnerability. We are building skyscraper favelas in code — in earthquake zones … Essentially, there is a lot of equivalent of “duct-tape” in the code, holding things together. If done right, that code will eventually be fixed, commented (explanations written up so the next programmer knows what the heck is up) and ported to systems built for the right scale — before there is a crisis. How often does that get done? I wager that many wait to see if the system comes crashing down, necessitating the fix. By then, you are probably too big to go down for too long, so there’s the temptation for more duct tape. And so on.

So what does this have to do with medicine?

Everything.

Today’s medicine practice was developed on the foundation of Cartesian dualism. (WRONG)

Dualism forced our scientific research to make an erroneous subject/object distinction. (possibly wrong, but we know no other way)

Simultaneously, our theories are tied to a Humean-interpretation of causality. (This too may be wrong; the conversation is still ongoing)

In the last few decades, we began to see that the mind influences the body and the body influences the mind in peculiar ways and that there are medically-unexplained symptoms that science cannot yet account for. We have begun to appreciate that there are holes in our thinking.

Is this starting to sound familiar? It should. History is our legacy code and it is full of exploits. But everything is progressing and working too well in medicine to start-over from scratch, so we get out our duct tape and fix it: we tape some -Psycho- and some -Social on our Biomedical-understanding and “Voila!” we have a new model/framework to use: a bio-psycho-social (BPS) approach. It is our Win10 to your Win8. Our Nougat 7.1 to your Jelly Bean 4.1. For the ultra-dorks, it is our Xenial Xerus to your Precise Pangolin.

And make no mistake, Win10, Nougat 7.1 and Xenial Xerus (that’s Ubuntu Linux, folks) all work better than any other operating system before them. They are an upgrade in almost every sense of the word. They afford us an opportunity to be more productive more quickly than ever before, yet the guys and gals behind the scenes — the ones who really understand the software that we are using — are terribly humble and aware of the many challenges that each system presents. They are vigilant as they continue to work on patch-after-patch and update-after-update to keep the entire system from crashing when we need it most.

So please, continue to work on, and hone your skills with, a BPS approach to care and call it whatever you want. Some folks prefer to call it patient-centered care. Some prefer to call it person-centered. Other still may call it humanistic. What you name it is not important so long as you consciously work to implement its unique perspectives into your care.

But, please, do not forget to remain humble and step into each patient encounter softly, carefully, and purposefully, because the BPS approach is just another skyscraper favela in an earthquake zone held together with duct tape.