The Black Liszt

The Nightmare of Covid Test Scheduling

Oh, you want to get a Covid test, do you? Little did you know that the clever people who do these things also give you endurance, patience and intelligence tests at the same time! Our wonderful healthcare people and helpful governments have somehow arranged a diverse number of ways to make you fill out varying forms in varying orders, only to find out that there are no available appointments.

Don’t you think the highly paid experts who created these services could have done something simple, like following the model of dimensional search used at little places like Amazon, travel sites and other places that care about customers? I guess that would have been too easy or something. And besides, medical scheduling in general is a nightmare, why should this be different?

Looking for a test: CVS

Search told me that my local CVS has testing. I clicked to the website of my local store. I clicked “schedule a test.” Although I had come from the local store, I guess the people who built covid testing didn’t manage to get the local site to pass on its location, so I entered my location again as requested.

Now I have to “answer a few questions” for no-cost testing. Eight questions. Then when I say yes to recent symptoms, 12 more questions plus the date my symptoms began. Then clicking that I was truthful.

Next, pick a test type, look at a map of local stores and see a list of dates starting today. I pick today. There’s a list of each store, with a button under each to “Check for available times.” Click on the first store. Here’s what appears:

There are no available times at this location for Tue., 12/21. Try searching for availability on another date.

Wow. I go up and pick the next day. Click. No times. Pick the next day. Click. No times.

CVS has pioneered a whole new way to help customers pick a time! You pick a date, pick a store, click and hope you get lucky. Then pick a different store and/or a different time and click again. And keep rolling until you hit the jackpot! Assuming there’s one there…

Since there was no end in sight, I tried something different.

Looking for a test: Walgreens

No questions first. Hooray! Just put in a location, pick a test type and see a list of locations. … Almost all of which had “No appointments available.” Let’s check out the one nearest to me, which said “Few appointments available.” I click. First I have to agree to lots of things. Now I have to enter my full patient information: name, gender, DOB, race, ethnicity, full address, phone and email. Then review and click that it’s correct.

Then, it’s the covid questions: my symptoms, contacts, medical conditions, pregnancy. Have I had vaccines? For each, which one and the date given. Have I tested positive in the past?

Now, after all that, I can pick an appointment. Back to that bait-and-switch first screen with test types and locations. I pick the location. Now a calendar shows up. Today’s date is highlighted. This message in red is below: “No time slots available within the selected date. Try a different date for more options.” The next 7 days are in normal type, beyond that they’re greyed out. Do any of them work? I try each day individually. They each give the same message! Why couldn’t you have told me that NO DATES WERE AVAILABLE!?!? Maybe even … BEFORE I filled all that stuff out??

Looking for a test: The state of NJ

Since I live in NJ, I get regular dispatches about how the state government cares about my health in general and covid in particular. So I went to the state site.

Which it turns out is operated by a private company, Castlight.

I put in my zip code. They list places that offer testing, one of which is the Walgreens I just tried. But I click on it anyway, and they link me to Walgreens testing … in a town 10 miles away instead of my town, which was explicitly the one I clicked on. Good job!

They got my hopes up by listing Quest Diagnostics, which has a location in my town. I answer a long list of questions and am told that I quality for a test! Hooray! But then …

I have to sign up and provide loads of personal information before even knowing I can get a test. That’s it for Quest.

Looking for a test: The local county

Maybe my local county would have done it better? Let’s check it out.

I get a long list of testing places. How do I find one near me? After a few minutes of confusion, I discover that the sites are listed alphabetically! Now that’s helpful!

CVS of course is near the top, with a line per location. My town isn’t listed even though I already know that the local CVS claims they do tests. Crap.

Looking for a test: Digging deep

I found a private place, Solv, that claims to link you right to testing places. I tried. They had a clinic not too far from me. Clicked. I’m still on Solv, which is potentially good. After more clicking It turns out that no appointments were available today or tomorrow, the only choices. Gee, Solv, maybe in the next release of your software you could possibly only show choices that were actually, you know, available??

I finally tried a little pharmacy that is local and has remained independent. They offer tests. I clicked and got to a page dedicated to the pharmacy under a place I’d never heard of, Resil Health. Right away they list dates and times available. Just a few days out.

I pick a date and enter the usual information on a clean form, but also my insurance information and a photo of the front & back of my card. Click. The time is no longer available! But at least picking another time was easy. I was disappointed that it was a couple days out. They sent an email with a calendar invite. I accepted. There was a link to reschedule. I tried it. To make a long story short, sometimes when I clicked reschedule the dates available changed, and earlier ones appeared. After some effort I snagged one the same day! Then I went. All I had to do was show my driver’s license – since they had everything else, neither I nor anyone at the pharmacy had to do paperwork – Resil health did it all, including the reporting.

It was a pain, but by far the best. Hooray for small-group entrepreneurs, getting a service up and running that makes things easier and better than any of the giant private companies and certainly any of the pathetic ever-so-helpful governments.

Looking for a test: Is it just me?

I had to wonder: is New Jersey particularly bad, as snotty New Yorkers like to joke about, or is it just the way things are? It turns out that, even in high-rise Manhattan, covid testing is tough. This article spells out the issues.

Mayor Bill de Blasio keeps telling New Yorkers frustrated with long waits and delayed results at privately-run COVID testing sites to use the city’s public options — but his administration’s incomplete and bulky websites make that exceedingly difficult.

It’s not just me.

Conclusion

I got my test. I’ll get the results soon. Let's hope getting those results is better than it often is in medicine. What’s the big deal? I’m only writing about it because it’s a representative story in the life-in-the-slow-lane of typical software development. It’s possible to write good software. Thankfully there are small groups of motivated programmers who ignore the mountain of Expert-sanctioned regulations, standards and processes that are supposed to produce good software. These software ninja’s have a different set of methods – ones that actually work! For example, in New York City:

The complaints echo the problems New Yorkers encountered when city officials first rolled out their vaccine appointment registration systems this spring — prompting one big-hearted New Yorker with computer skills to create TurboVax to workaround the mess.

“We don’t have a single source of truth for all testing sites in NYC,” tweeted the programmer, Huge Ma, who was endearingly dubbed ‘Vax Daddy’ by grateful Gothamites. “Tech can’t solve all problems but it shouldn’t itself be a problem on its own.”

One guy – but a guy who actually knows how to produce effective, working software in less time than the usual software bureaucracy would take to produce a first draft requirements document. This is one of the on-going stream of anomalies that demonstrate that a paradigm shift in software is long overdue.

The Dimension of Automation Depth in Information Access

I have described the concept of automation depth, which goes through natural stages starting with the computer playing a completely supportive role to the person (the recorder stage) and ending with the robot stage in which the person plays a secondary role. I have illustrated these stages with a couple examples that illustrate the surprising pain and trouble of going from one stage to the next.

Unlike the progression of software applications from custom through parameterized to workbench, customers tend to resist moving to the next stage of automation for various reasons including the fear of loss of control and power.

Automation depth in Information Access

Each of the patterns of software evolution I've described are general in nature. I’ve tried to give examples to show how the principles are applied. In this section, I’ll show how the entire pattern played out in “information access,” which is the set of facilities for enabling people to find and use computer-based information for business decision making.

Built-in Reporting

“Recorder” is the first stage of the automation depth pattern of software evolution. In the case of information access, early programs were written to record the basic transactions that took place; as part of the recording operation, reports were typically produced, summarizing the operations just performed. For example, all the checks written and deposits made at a bank would be recorded during the day; then, at night, all the daily activity would be posted to the accounts. The posting program would perform all the updates and create reports. The reports would include the changes made, the new status of all the accounts, and whatever else was needed to run the bank.

At this initial stage, the program that does the recording also does the reporting. Reporting is usually thought to be an integral part of the recording process – you do it, and then report on what you did. Why would you have one program doing things, and a whole separate program figuring out and reporting on what the first program did? It makes no sense.

What if you need reports for different purposes? You enhance the core program and the associated reports. What if lots of people want the reports? You build (in the early days) or acquire (as the market matured) a report distribution system, to file the reports and provide them to authorized people as required.

Efficiency was a key consideration. The core transaction processing was “touching” the transactions and the master files; while it was doing this, it could be updating counters and adding to reports as it went along, so that you wouldn’t have to re-process the same data multiple times.

Report Writers

The “power tool” stage of automation depth had two major sub-stages. The first of these was the separation of reporting from transaction processing. Information access was now a key goal in itself, and was so important and done so frequently that specialized tools were built to make it easy, which is always the sign that you’re into the “power tool” phase.

This first generation of power tools were specialized software packages generally called “report writers.” The power tool was directed at the programmer who had to create the report. Originally, the language that was used for transaction processing was also used for generating the report. The most frequent such language was COBOL. The fact that COBOL was cumbersome for this purpose was reflected in the fact that specialized syntax was added to COBOL to ease the task of writing reports. But various clever people saw that by creating a whole new language and software environment, the process of writing reports could be tremendously enhanced and simplified. These people began to think in terms of reporting itself, so naturally they broke the problem into natural pieces: accessing the data you want to report on, processing it (select, sort, sum, etc.), and formatting it for output.

The result of this thinking was a whole industry that itself evolved over time, and played out in multiple environments and took multiple forms. The common denominator was that they were all software tools to enable programmers to produce reports more quickly and effectively than before, and were complete separate from the recorder or transaction processing function.

At the same time, data storage was evolving. The database management system emerged through several generations. This is not the place for that story, which is tangential to the automation depth of information access. What is relevant is that, as the industry generally recognized that information access had moved to the report writer stage of automation, effort was made to create a clean interface between data and the programs that accessed the data for various purposes.

Data Warehouse and OLAP

Report writers were (and are) important power tools – but they’re basically directed at programmers. But programmers are not the ultimate audience for most reports; most reports are for people charged with comprehending the business implications of what is on the report and taking appropriate action in response. And the business users proved to be perennially dissatisfied with the reports they were getting. There was too much information (making it hard to find the important things), not enough information, information organized in confusing ways (so that users would need to walk through multiple reports side-by-side), or information presented in boring ways that made it difficult to grasp the significance of what was on the page. And anytime you wanted something different, it was a big magilla – you’d have to get resources authorized, a programmer assigned, suffer through the work eventually getting done, and by then you’d have twice as many new things that needed getting done.

As a result of these problems, a second wave of power tools emerged, directed at this business user. These eventually were called OLAP tools. The business user (with varying levels of help from those annoying programmers) had his own power tool, giving him direct access to the information. Instead of static reports, you could click on something and find out more about it – right away! But with business users clicking, the underlying data management systems were getting killed, so before long the business users got their own copy of the data, a data warehouse system.

In a sign of things to come, the business users noticed that sometimes, they were just scanning the reports for items of significance, and that it wasn’t hard to spell out exactly what they cared about. So OLAP tools were enhanced to find and highlight items of special significance, for example sales regions where the latest sales trends were lower than projections by a certain margin. This evolved into a whole system of alerts.

Predictive Analytics

OLAP tools are certainly power tools, but the trouble with power tools is that you need power users – people who know the business, can learn to use a versatile tool like OLAP effectively, and can generate actions from the information that help the business. So information access advanced to the final stage in our general pattern, the “robot” stage, in which human decision making is replaced by an automated system. In information access, that stage is often called “predictive analytics,” which is a kind of math modeling.

As areas of business management are better understood, it usually turns out that predictive analytics can do a better, quicker job of analyzing the data, finding the patterns, and generating the actionable decisions than a person ever could. A good example is home mortgage lending, where the vast majority of the decisions today are made using predictive analytics. Many years ago, a person who wanted a home mortgage would make an appointment with a loan officer at a local savings bank and request the loan. The officer would look at your information and make a human judgment about your loan worthiness.

That “power user” system has long since been supplanted by the “robot” system of predictive analytics, where all the known data about any potential borrower is constantly tracked, and credit decisions about that person are made on the basis of the math whenever needed. No human judgment is involved, and in fact would only make the system worse.

Predictive analytics is the same in terms of information utilization as the prior stages, but the emphasis on presenting a powerful, flexible user interface to enable a power user to drive his way to information discovery is replaced by math models that are constantly tuned and updated by the new information that becomes available.

Sometimes the predictive analytics stage is held back because of a lack of vision or initiative on the part of the relevant industry leaders. However, a pre-condition for this approach really working is the availability of all the relevant data in suitable format. For example, while we tend to focus on the math for the automated mortgage loan processing, the math only works because it has access to a nationwide database containing everyone’s financial transactions over a period of many years. A power user with lots of experience, data and human judgment will beat any form of math with inadequate data; however, good math fueled with a comprehensive, relevant data set will beat the best human any time.

Conclusion

All these stages of automation co-exist today. One of the key rules of computing is that old programs rarely die; they just get layered on top of, given new names, and gradually fade into obscurity. There are still posting programs written in assembler language that have built-in reporting. In spite of years of market hype from the OLAP folks, report writing hasn’t gone away; in fact, some older report writers have interesting new interactive capabilities; OLAP and data warehouses are things that some organizations aspire to, while others couldn’t live without them; finally, there are important and growing pockets of business where the decisions are made by predictive analytics, and to produce pretty reports for decision-making purposes (as opposed to bragging about how well the predictive analytics are doing) would be malpractice.

Even though all these stages of automation co-exist in society as a whole, they rarely co-exist in a functional segment of business. Each stage of automation is much more powerful than the prior stage, and it provides tangible, overwhelming advantages to the groups that use it. Therefore, once a business function has advanced to use a new stage of information access automation, there is a “tipping point,” and it tends to become the new standard for doing things among organizations performing that function.

Trusting Science: the Whole Milk Disaster

I trust science. The gradual emergence of science has led to a revolution in human existence that has happened so quickly and with such impact that it is hard to gain perspective on it.

Trusting science is not the same as trusting the pronouncements of people who are designated scientific experts. Establishing the truth of a scientific theory is an entirely different process than the social dynamics of rising to a position of leadership in a group of any kind. Official experts, whether government, corporate or academic, nearly always defend the current version of received truth against challenge of all kinds; most of those challenges are stupidity and ignorance. My go-to expert on this subject, as so many others, is Dilbert:

Sadly, those same establishment experts tend to be the strongest opponents of genuine innovation and scientific advances of all kinds. As I explain here, with examples from Feynman and the history of flight, one of the core elements of successful innovation is ignoring the official experts.

My skepticism is well proven in the case of so-called Computer Science, which doesn't even rise to the level of "useful computer practices" much less science. As I have shown extensively, Computer Science and Engineering is largely a collection of elaborate faith-based assertions without empirical foundation. And computers are all numbers and math! If it's so pathetic in such an objective field, imagine how bad it can get when complex biological systems are involved.

This brings us to the subject of saturated fat (solid fat of the kind that's in meat), whole milk and human nutrition. This ongoing scandal -- for which no one has been imprisoned, sued or even demoted -- in spite of its leading to widespread obesity and other health-damaging conditions -- is still rolling along. The hard science concerning the supposed connection between saturated fat, cholesterol and heart disease is in. The results are clear. It is positively healthy for people to eat saturated fat. Period. The scandal is that the "expert" people and organizations that have declared saturated fat and cholesterol to be dangerously unhealthy for many decades refuse to admit their errors and continue to waffle on the subject.

This is relevant to computer science because of the stark differences between the two fields. Software is esoteric and invisible to nearly everyone, while the results of eating are tangible to everyone, and the statistics about the effects are visible and measurable. The common factor is ... people. In both cases there is a wide consensus of expert opinion about the right way to build and main software, and the right way to eat and live in order to be healthy. Experts! From blood-letting to flying machines, they lead the way!

Usually the Science-challengers are wrong

It has taken me a great deal of time to dig in to this scandal, in part because there are so many cases of "the experts are all wrong -- me and my fringe group have the truth." I wanted to make absolutely sure "it's good to eat saturated fat" wasn't another of these. After all, the simple notion that eating fat makes you fat makes common sense!

The Scandal

Surely the diet recommendations of the major medical and government institutions in favor of limiting fat must be valid! Sadly, this is not the case. Rather, it's a wonderful example of how hard paradigm shifts are to accomplish, particularly when the prestige of major institutions are involved. And, sadly, how prestige and baseless assertions have substituted for science, shockingly similar to bloodletting and other universally-accepted-on-no-objective-basis practices.

A basic, understandable summary of the subject may be found in The Big Fat Surprise, which is loaded with appropriate detail. Here is a summary:

"the past sixty years of low-fat nutrition advice has amounted to a vast uncontrolled experiment on the entire population, with disastrous consequences for our health.

For decades, we have been told that the best possible diet involves cutting back on fat, especially saturated fat, and that if we are not getting healthier or thinner it must be because we are not trying hard enough. But what if the low-fat diet is itself the problem? What if those exact foods we’ve been denying ourselves — the creamy cheeses, the sizzling steaks — are themselves the key to reversing the epidemics of obesity, diabetes, and heart disease?"

Yes, this sounds like what an anti-science crank would say. All I can say is, dig in. You'll find the shoddy beginnings of the fat-cholesterol-heart hypothesis; the biased studies that seemed to support it; the massive, multi-decade Framingham study which was trumpeted as supporting the anti-fat theory, but whose thoroughly confirmed and vetted results were actively suppressed for many years; the uncontested studies that disprove the anti-fat recommendations; and the improved understanding of the biological systems that thoroughly debunks the widely promoted campaign against saturated fat and LDL, the "bad" cholesterol.

More detail

If you want a start on more detail, I recommend Dr. Sebastian Rushworth at a high level and the recent book by long-term cardiac doctor Malcolm Kendrick that gives the details of the studies and biology that explain what really happens.

Here are a couple explanations from Dr. Rushworth:

"the LDL hypothesis basically says that heart disease happens because LDL somewhow ends up in the arterial wall, after which it is oxidized, which starts an inflammatory reaction that gradually leads to the hardening of arteries and eventually to bad things like heart attacks and strokes."

"... the LDL hypothesis is bunk. There is by now a wealth of evidence showing that LDL has little to do with heart disease, such as this systematic review from BMJ Evidence Based Medicine, which showed that there is no correlation whatsoever between the amount of LDL lowering induced by statins and other LDL lowering drugs, and the benefit seen on cardiovascular disease risk (if indeed any benefit is seen – it often isn’t)."

Rushmore's summary of the Kendrick book is:

"The ultra-short elevator pitch version of what he argues in the book is that heart disease is what happens when damage to the arterial wall occurs at a faster rate than repair can happen. That’s why everything from sickle cell disease to diabetes to high blood pressure to smoking to rheumatoid arthritis to cortisone treatment to the cancer drug Avastin increases the risk of cardiovascular disease – they all either increase the speed at which the arterial wall gets damaged or slow down its repair. It’s why heart disease (more correctly called “cardiovascular disease”) only affects arteries (which are high pressure systems) and not veins (which are low pressure systems), and why atherosclerosis (the hardening of the arteries that characterizes heart disease) primarily happens at locations where blood flow is extra turbulent, such as at bifurcations.

This alternative to the LDL hypothesis is known as the “thrombogenic hypothesis” of heart disease. It’s actually been around for a long time, first having been proposed by German pathologist Carl von Rokitansky in the 19th century. Von Rokitansky noted that atherosclerotic plaques bear a remarkable similarity to blood clots when analyzed in a microscope, and proposed that they were in fact blood clots in various stages of repair.

Unfortunately, at the time, von Rokitansky wasn’t able to explain how blood clots ended up inside the artery wall, and so the hypothesis floundered for a century and a half (which is a little bit ironic when you consider that no-one knows how LDL ends up inside the artery wall either, yet that hasn’t hindered the LDL hypothesis from becoming the dominant explanation for how heart disease happens). We now know the mechanism by which this happens: cells formed in the bone marrow, known as “endothelial progenitor cells”, circulate in the blood stream and form a new layer of endothelium on top of any clots that form on the artery wall after damage – thus the clot is incorporated in to the arterial wall.

In spite of the fact that probably at least 99% of cardiologists still believe in the LDL hypothesis, the thrombogenic hypothesis is actually supported far better by all the available evidence. While the LDL hypothesis cannot explain why any of the risk factors listed above increases the risk of heart disease, the thrombogenic hypothesis easily explains all of them.

Conclusion

Many major institutions have dialed down their fervent condemnation of the low-fat and LDL-is-bad myths, but haven't done what they should do, which reverse their positions and mea culpa. They should at minimum take at least part responsibility for the explosion of obesity, useless pharma mega-dollars wasted, and the attendant health disasters for countless humans. The fact that they're not helps us understand the resistance to correction of the similarly powerful mainstream myths about software. It's not about the LDL or the software; it's about people, pride, institutions, bureaucracy and entrenched practices and beliefs that fight change.