The Black Liszt

Author: David B. Black

  • The Aftermath of the Net Neutrality Disaster

    After many years of fighting against entrenched corporate interests, the FCC finally extended its regulatory authority to the internet, instituting the so-called "net neutrality" rule in 2015. Finally, the internet would remain free and open.

    Then a new administration came in, with new leadership at the FCC. There was a move to repeal the common-sense principle of "net neutrality!" Why would anyone think that letting giant corporations pick and choose what we can see on the internet was a good idea, making things they didn't like too expensive or simply blocked — crazy! It's kind of like repealing the laws against murder, hoping that people would just not do it!

    Some leading Democrats made it clear what would happen if net neutrality were repealed:

    Nn 1

    Nn 2

     

    The senate was being careful here — what about ISP's blocking access to sites they don't want you to see? Senate leaders were outspoken about the danger:

    Merlin_138259401_bf9699d4-f086-4d70-81d0-2316053ebb2f-jumbo

    People were upset. There were demonstrations at more than 700 Verizon stores nationwide:

    Dqdo4vcw4aetpbk.jpg-large

    Protestors even spread out through the new FCC chairman's neighborhood, demonstrated in front of his house, took pictures of the inside of his house through his windows, and made it clear that this man, Ajit Pai, was leading the movement to destroy the internet as we know it.

    After a vote near the end of 2017 to repeal this important protection, the repeal finally took effect in June 2018, about a year ago. That's when the disaster of corporate control of the internet, access limitations, slower speeds and no more innovation started. Articles were written in the NY Times and elsewhere spelling out what would happen: "repealing these onerous rules “would be the final pillow in (the internet’s) face” (The New York Times), would cause “erosion of the biggest free-speech platform the world has ever known” (ACLU), and would be “end of the internet as we know it” (CNN)."

    It's now about a year into the disaster. I started looking into just how bad it's been and was struck by how hard it is to find the news stories about all the sites that have been blocked, all the students relegated to slow lanes and prevented from watching their favorite video streams, and all the price hikes. Have the giant corporations really been so scarily effective at suppressing the consequences of their self-serving actions?

    I dug in and found this:

    Last year, average internet download speeds shot up almost 36%, and upload speeds climbed 22%, according to internet speed-test company Ookla in its latest U.S. broadband report.

    There are more users than ever. More videos to watch. More content to consume. More commerce being conducted. No sites are being blocked. No one is complaining that their service is being throttled. And more people are gaining access to broadband.

    During President Trump’s first year in office, in fact, the number of people without access to a broadband connection dropped by 18%.

    Meanwhile, the 5G era approaches, which will increase speeds — for mobile and fixed broadband — exponentially while injecting more competition among providers.  Elon Musk’s SpaceX has started launching mini-satellites for his Starlink initiative, which will provide broadband internet to subscribers wherever they are on the planet. 

    Oops. Maybe the disaster isn't a disaster at all. Maybe it's even a good thing, hard as that may be to understand. Here's what I wrote about it when repealing net neutrality was being discussed, and here's the long post I wrote on the subject when the campaign to institute net neutrality was underway.

    p.s. That earlier post on net neutrality touched a few nerves. A few programmers at companies I worked with got all hot and bothered, and refused to interact with someone so completely unethical that they could harbor such awful thoughts. Well, now we know how it all turned out, and what the repeal-net-neutrality disaster amounted to…

  • Adventures with Health System Software: Customer Feedback

    If you want a cheap laugh, go to the Mount Sinai medical system website and hope they ask you to complete an opinion survey. It’s stupid and ridiculous, deserving lots of snark. But try not to think about what it means or the underlying reality, or you might get kinda depressed. Like I did, because I went to the website because I needed to get something done! I needed a phone number. Sounds simple, right? Until you understand I had already talked with someone at Mount Sinai, and that person gave me the wrong number. But I really needed the number — I needed to make an appointment for a medical test that is crucial to my health. After a great deal of searching, I finally found what appeared to be the right number. Except it wasn't, as I found when I called.

    This was part of my epic struggle to schedule an appointment — something that I do with a couple clicks for my favorite restaurants, my cat at the animal hospital, or … yes, my primary care provider. But at that powerhouse medical institution, Mount Sinai? Only the best people who really, really, really want an appointment are graciously granted one. See this for the story.

    In this post, I'll confine myself to glancing at the carefully constructed Mount Sinai website and the extraordinary steps they are taking to assure that it is the best it can be. It's clear they're in a race for the top with the health insurance companies on this subject, see this.

    Major companies that build websites have a problem, a problem they share with lots of companies that build software. The executives in charge are required to say that they care about quality, and do everything in their power to track and improve it, along with important metrics involving customer satisfaction. They take concrete steps to measure quality, using the best firms out there to help them.

    There's just a little problem: they can't get it done.

    The Mount Sinai website

    I recently encountered a typical example of hopeless executive incompetence while trying to get a simple phone number to schedule a visit to Mount Sinai Hospital in NYC – scheduling that any institution whose software had successfully made the wrenching transition to the 2,000’s would have made long ago. I tell the story of the scheduling adventure here.

    It was a long slog to get my MRI appointment made, including a number of calls and emails. You might think that when a window popped up near the end of my ultimately unsuccessful trek through the Mount Sinai website to extract a simple phone number that I would ignore it. After all, the website is a carefully-crafted, attractive-looking piece of useless fluff, impressive perhaps to the important people who are shown images of it in a Powerpoint presentation during some meeting, but in fact annoying, error-filled and generally useless to real people. Silly me: here I am thinking that the hoi-polloi, the real people who have health issues, are the relevant people here – when in reality, it’s the executives, jockeying for ever-growing power, prestige and money among themselves.

    Mount Sinai opinion

    If you’ve read any of my other posts on software quality, you may suspect that I’m a glutton for punishment. Your suspicions are correct. So I agreed to take the survey. When I left the site, I expected the survey to pop up, but it didn’t. After all, the request told me, in no uncertain terms, “it will pop up when you leave the site.” OK, I thought, your loss, not mine. But darn! The survey I recently got from my health insurance company was so juicy!! I would have loved to see who wins the race for most dysfunctional survey between a major provider and a major payer!

    It turns out, I just needed to wait. Before long, the survey arrived in an email:

    Mount email

    I was a bit surprised to get the request in this way, but OK, they’ve obviously got all my information, so fine. As usual, I hover over the link to make sure it’s legit. The URL was portal.gsight.net with some codes after. I quickly discovered this was a domain owned by the company that sent me the email, Greystone.net. Hmmm, who are they?

    Greystone

    Wow, a whole company devoted to healthcare marketing and the internet! They must be really good! I wonder if they know about the web?

    Gsight 1

    It appears they know about the Web. And look at this:

    Gsight 2

    It’s a whole process to make the website great! Smart folks, those people at Mount Sinai, turning to professional specialists to figure out how well their website is serving their customers! Though I can only assume that Greystone has only recently been engaged, since the Mount Sinai website is, after all, a pretty-looking pile of stinking crap…

    So let’s dig into this expert opinion survey. Click. Here’s where I land:

    Mount survey 1

    OMG!!! My jaw has hit the floor so heavily, I’ll probably be scarred for life. I wonder if I can sue Greystone to cover the costs of plastic surgery for my deformed, floor-mangled jaw??

    Why is my jaw hurting? Because the link these consummate professionals sent me was to a completely generic landing page! There is this thing known as “deep linking,” in which the custom URL you click brings you right to the place in question. It’s widely used. The landing page knows who you are and why you’re there. I guess the folks at Greystone hired a bunch of interns for this project, ones who hadn’t gotten to that chapter in the “Internet Linking for Dummies” book. And no one with the slightest bit of experience, like the average internet user, had tried it out.

    After I gave the right answer, I was thrown into a completely generic survey about the website, utterly uninformed about who I was or any smidgen of knowledge about my site visit – putting the lie to the user tracking they supposedly do. Had they done elementary user tracking, they would have known who I was and which pages of the site I had visited. But no, they decided to ask completely generic questions.

    Is this hard to do? Nope. For example, my bank, USAA, notices when I go to the “wire transfer” section of their website and then call them. A recorded voice says something like “I see you’ve recently visited the money transfer section of the USAA website; would you like to wire money today, David?” If I answer “yes,” they transfer me to the relevant department. Not hard! Maybe the Greystone.net interns will eventually get to that chapter.

    The survey itself was endless, irrelevant awfulness.

    Here’s an example of why the survey was awful:

    Mount survey 30

    If they had tracked me and made the survey specific, they would have known that I hadn’t filled out a form. Instead, they present me with a question about form-filling, and then require an answer. Most of the questions were like this. By the way, this question was about … the twentieth question — all of them response is required. See the progress bar that says 25%? At some point, it jumped to that, and then, question after question, it didn't changed.

    Then at the end, I was invited to give some input. Which I did in calm language, mentioning that it might be nice if the phone numbers on the site were, you know, correct numbers. Of course, since they hadn't deep-linked, they had no way of contacting me to get further information.

    Just to be sure I wasn't completely nuts, I went onto the Mount Sinai website again. I got lucky — an invitation to complete an opinion survey popped up again. I carefully chose "take it after leaving the site," and this time it worked, though in a remarkably clunky way, indicating that whoever built the code had flunked Javascript 1.01. So I get the survey, and was blown away by seeing the very same "how did you get here" question I got from the email link. Any competent web programmer could know how I got there, by looking at exactly how the original URL was invoked. Clearly, performing this elementary task was beyond the collective genius of Greystone and Mount Sinai.

    Then as I went farther into the brain-dead survey, I discovered that it just didn't work. Look at this:

    Capture

    Look at the percent completion bar just below the black line under the Mt Sinai logo — it's still at zero, even though I'm many questions into it, as you can see by the scroll bar on the right. Programming and QA 1.01. Fail. And of course, it was a survey designed so that no normal person would march all the way through to completion.

    Discussion

    There’s a concept in math and computing, and also in real life, called “recursion,” or sometimes self-reference. It’s a simple concept; it’s been around for literally thousands of years, as we know from fun statements ancient Greeks made involving lying Cretans. In this case, it applies to the question of the quality checkers: who checks the quality of the quality checkers?

    The answer is evidently “no one.” The most basic principles in surveys, common sense but also proven by experience, are “keep it short” and “Make every question matter.” We know these are the relevant principles because everyone who hasn’t failed the “survey 1.01” course knows that the most important metric to measure is drop-out rate. Of the people you invite, how many accept? Of those who accept, how far in the survey do they get before dropping out? What’s the completion rate? Any tracking along these lines would have shown minuscule completion rates. I’d love to have a recording of the executive meeting at Mount Sinai in which the survey results were presented, to see whether the issue was even raised.

    But beyond that, let me ask: when was the last time you got a survey from Google? Or Amazon? Never, right? Another thing: have you read even a little bit about opinion polling, about how it's long-since been proven that people give one answer when asked, but then act differently? What people who are moderately educated web professionals know is that surveys are useless! That's why folks who know a little about websites watch what you do! If there's a lot of information on the site, they make it search-based, with lots of suggestions. They look for drop-outs.

    Yes, I've made fun of how badly the survey was constructed and executed. It was the electronic equivalent of a paper survey from 50 years ago. Which makes sense, because the Mount Sinai website is the electronic equivalent of  a glossy brochure from 50 years ago. That's the killer observation. Mount Sinai could make a huge advance by leaping forward to the state of the art of roughly 20 years ago. The very fact that they're using obsolete technology like surveys — and on top of it doing it incompetently — shows that they are clueless. It's the equivalent of using a steam-powered car instead of an oil-powered one, and being unable to run the steam-powered car competently. The right response here isn't build a better survey — it's use modern customer feedback techniques.

    Conclusion

    Well, it’s a wash. The hospital system opinion survey was pretty different from the health insurance one, but they each exemplified unique ways of being bad. I wonder how many dimensions of badness there are? The institutions I’ve had the pleasure of experiencing are clearly on the leaderboard of those most likely to get to the maximum. Neither of them has a clue about decades-old methods that are vastly superior for getting customer feedback than surveys, however well-constructed those surveys might be.

    Postscript

    Learning about the excellent survey work conducted by Greystone.net on behalf of Mount Sinai had an added dimension of amusement for me because I grew up near an institution named Greystone. Or more formally, Greystone Park Psychiatric Hospital.

    Greystone pic

    It was, as my mother the R.N. called it when I was growing up, a ‘Looney bin.” If someone said something she thought was dumb, she would say “Did you just escape from Greystone?”

  • Recurring Software Fashion Nightmares

    Computer software is plagued by nightmares. The nightmares vary.

    Sometimes they are fundamentally sound ideas that are pursued in the wrong way, in the wrong circumstances or at the wrong time. Therefore they fail – but usually come back, sometimes with a different name or emphasis.

    Sometimes they’re just plain bad ideas, but sound good and are cleverly promoted, and sound like they may be relevant to solving widely acknowledged problems. Except they just don’t work. Sometimes these fundamentally bad ideas resurface, sometimes with a new name.

    Sometimes they’re a good idea for an extremely narrow problem that is wildly applied beyond its area of applicability.

    The worst nightmares are the ones that slowly evolve, take hold, and become widely accepted as part of what “good programmers” believe and do. Some of these even become part of what is ludicrously called “computer science.” Foundation stones such as these, accepted and taught without proof, evidence or even serious analysis, make it clear to any objective observer that computer “science” is anything but scientific, and that computer “engineering” is a joke. If the bridges and buildings designed by mechanical engineers collapsed with anything close to the frequency that software systems malfunction, the bums and frauds in charge would have long since been thrown out. But since bad software that breaks is so widespread, and since after all it “merely” causes endless delays and trouble, but doesn’t dump cars and trucks into the river, people just accept it as how things are. Sad.

    Following is a brief review of sample nightmares in each of these categories. Some of what I describe as nightmares are fervently believed by many people. Some have staked their professional lives on them. I doubt any of the true adherents will be moved by my descriptions – why should they be? It was never about evidence or proof for the faithful to start with, so why should things change now?

    Sound Ideas – but not here and now

    • Machine learning, AI, OR methods, most analytics.
      • These things are wonderful. I love them. When properly applied in the right way by competent people against the right problem at the right time, amazing things can be accomplished. But those simple-sounding conditions are rarely met, and as a result, most efforts to apply these amazing techniques fail. See this.

    Bad ideas cleverly promoted

    • Microservices.
      • Microservices are currently what modern, transformative CTO’s shove down the throats of their innocent organizations, promising great things, including wonderful productivity and an end to that horror of horrors, the “monolithic code base.” While rarely admitted, this is little but a re-incarnation of the joke of Extreme Programming from a couple decades ago, with slightly modified rhetoric. A wide variety of virtues are supposed to come from micro-services, above all scalability and productivity, but it’s all little but arm-waving. If software valued evidence even a little, micro-services would be widely accepted as the bad joke it is.
    • Big Data
      • There's nothing wrong in principle with collecting data and analyzing it. But in practice, the whole big data effort is little but an attempt to apply inapplicable methods to random collections of data, hoping to achieving generic but unspecified benefits. See here.

    Great ideas for a narrow problem

    • Blockchain.
      • My favorite example of an excellent solution to a problem that has been applied way beyond its area of legitimate application is blockchain. Bitcoin was a brilliant solution to the problem of having a currency that works with no one in charge. How do you get people to “guard the vault” and not turn into crooks? The way the mining is designed with its incentives and distributed consensus scheme brilliantly solves the problem. However, the second you start having loads of crypto-currencies, things get weaker. Once you introduce “smart contracts,” there’s a fly in the ointment. Take away the currency and make it blockchain and you’ve got a real disaster. Then “improve” it and make it private and you’ve got yourself a full-scale contradiction in terms that is spectacularly useless. See here.

    Bad ideas that are part of the Computer Science and Engineering canon

    • Object-orientation.
      • Languages can have varying ways of expressed data structures and relating to them. A particular variant on this issue called “object-orientation” emerged decades ago. After enjoying a heyday of evangelism during the first internet bubble, O-O languages are taught nearly universally in academia to the exclusion of all others, and adherence to the O-O faith is widely taken to be a sign of how serious a CS person you are. For some strange reason, no one seems to mention the abject failure of O-O databases. And no one talks about serious opposing views, such as that of Linus Torvalds, the creator/leader of the linux open source movement, which powers 90% of the world's web servers. Programmers who value results have long since moved on, but academia and industry as a whole remains committed to the false god of O-O-ism.
    • Most project management methods.
      • I’ve written a great deal about this, including a book. Whether it’s the modern fashion of Agile with its various add-ons such as SCRUM, project management methods, ripped from other disciplines and applied mindlessly to software programming, have been an unmitigated disaster. The response? It ranges from “you’re not doing it right,” to “you need to use cool new method X.” Yet, project management is a profession, with certifications and course on it taught in otherwise respectable schools. A true nightmare. See these.
    • Most software QA methods.
      • All software professionals accept what they’ve been taught, which is that some kind of software automation is an essential part of building software that works and keeping it working. Except the methods are horrible, wasteful, full of holes and rarely make things much better. See this.

    Conclusion

    I make no claim that the list of items I’ve discussed here is comprehensive. There are things I could have included that I have left out. But this is a start. Furthermore, if just half the items I’ve listed were tossed and replaced with things that actually, you know, worked, much better software would be produced more quickly than it is today. I don’t call for perfection – but some progress would sure be nice!

  • Blockchain has been Unchained and Unblocked and it’s Broken

    Blockchain promoters and enthusiasts continue to blithely stroll along the yellow blockchain road to the golden city where immutable distributed ledgers make decades-long technology problems fade away, like the wicked witch. None them publicly acknowledges or seems to notice the hurricanes and earthquakes that are increasing in frequency and intensity.

    In total, hackers have stolen nearly $2 billion worth of cryptocurrency since the beginning of 2017, mostly from exchanges, and that’s just what has been revealed publicly.

    That’s no big deal, I guess. I describe these little security problems here and here.

    Someone who’s technically sophisticated could argue, following the logic I described here, that the security problem wasn’t in Blockchain itself. The problem was in wallets and exchanges, which are software that sits “on top of” blockchain, making it easier to use. It’s the same kind of security breach that can happen with any software, and has little to do with the inherent security of the software itself, but is mostly due to the layers of software built on top. This is true! One does wonder why Blockchain is so wonderful, then, if in practical use, its supposed greater security is so easily circumvented.

    Is it really more secure than a regular DBMS, putting aside all those flaky higher layers of software? That’s what everyone involved declares. The most open and honest of the Blockchain-ista’s will grudgingly admit that a nearly impossible 51% attack could cause a bit of a problem with the heart of the system, the keep of the blockchain castle.

    Sadly, the nearly impossible attack has happened. And not with some obscure little crypto-currency no one has ever heard of, but with Ethereum Classic, one of the premier systems, and the home of that transformative invention, the Smart Contract.

    An attacker had somehow gained control of more than half of the network’s computing power and was using it to rewrite the transaction history. That made it possible to spend the same cryptocurrency more than once—known as “double spends.” The attacker was spotted pulling this off to the tune of $1.1 million.

    To anyone with a shred of common sense, this is a fatal event. It demonstrates that Blockchain’s security has a fatal flaw, even when running in its optimal environment, with public miners.

    The big companies promoting private blockchains, should they deign to pay attention, will immediately come back with strong statements about how that kind of attack could only take place in a public blockchain, and couldn’t possible happen with a highly secure, controlled environment they provide with their private blockchain. Sure. That’s like saying that those guys who stole lots of money in the open, in a big public space where everyone could see them, couldn’t possibly get into the single secret room and rob the bank vault in complete privacy. Security in closed computer system managed by big companies who follow all the security regulations and pass audits is abysmal. Ever hear of Edward Snowden? Chelsea Manning? Others? Check out the facts a bit, and then come back to me and explain how it is that the unbroken stream of security breaches of the best systems run by the best military and corporate bureaucracies is going to suddenly stop when the software at the core is Blockchain.

    The sad fact is, libraries are more secure than computer systems. Including when Blockchain is involved.

    This post first appeared at Forbes.

  • What’s Wrong with Medical Scheduling and Why it Matters

    It’s easier by far to make a reservation at a restaurant than for a medical test. I guess having a meal at a restaurant is far more important than getting an MRI, given that the restaurant people have made the process simple and convenient and effective for all concerned. Getting a medical test must be rare and unimportant, since no one has bothered to make it work well. Sure. I guess that lie is more comfortable than the other possibility, which is that medical system administrators and software providers are too incompetent, lazy or unmotivated  to make things moderately convenient and up-to-date for their employees and customers.

    Why this is an important issue

    If you’ve gotten this far, you’re already an unusual reader. The vast majority of the leaders, innovators, experts and generally high-prestige people in healthcare would have tuned out and moved on as soon as they saw “medical scheduling.” Their guts tell them “medical scheduling isn’t important.” In terms of career growth and industry prestige, their guts are serving them well.  However, in terms of making a real difference that will positively impact most people involved in medicine, their guts are misleading them.

    Medicine has a real prestige problem. I’ve described the medical innovation spectrum, in which the exotic, future-oriented end, like AI and Blockchain, gets most of the money, conferences, attention and career-advancing opportunities. The more you move on the spectrum to simpler, proven, non-exotic things that can make a difference here and now for lots of people, the more you’re moving to the back office or basement, where poorly-paid, invisible people while away their time and whine to no meaningful audience. Here are details and examples.

    Scheduling is one of those proven winners that remains largely unimplemented in major medical organizations. The fact that scattered medical groups have implemented it beautifully shows there are no technical barriers.

    I can hear it now. Scheduling. Sure. What award am I going to win by implementing something restaurants do? I’m breaking new ground in personalized medicine while I’m curing cancer on the side! Away with your trivial scheduling talk!

    I get it. There’s just a little problem. As I’ve detailed here and here and here and here and more, time and money loss and serious medical issues are caused by nuts-and-bolts problems in the medical system. If just some of them were improved, the funding for your precious futuristic projects could be increased! And, by the way, loads of patients would be better off on multiple dimensions, including not dying prematurely! You know, little things.

    As an example of the impact, consider just this aspect of scheduling: automated follow-up (yes, it’s part of scheduling). Failure of follow-up problems:

    “The impact on patient outcomes included missed cancer diagnoses.” Journal of General Internal Medicine.

    “In fact, almost a quarter of all medical errors occurring in outpatient settings can be attributed to poor follow-up of abnormal test results and are believed to represent 25% of malpractice lawsuits involving failures or delays in diagnosis.” AACC

    The Scheduling problem

    There are an amazing number of dedicated, skilled, hard-working professionals in medicine. There are patients who have health issues who are often grateful for the service and care provided by those professionals. But both groups, providers and patients, are burdened by ancient, dysfunctional and incredibly expensive processes and computer systems that make things that should be quick and easy into something that is cumbersome and time-consuming, often yielding poor results. Everyone involved feels trapped and needlessly harassed. What’s going on here?

    This is the horrible general scheduling problem in health care. To illustrate the issues in a concrete way, I’ll focus on scheduling a test as a follow-on to a procedure, and use my own experience as an example – an example that, sadly, is business-as-usual in this world.

    A Cat Scheduling Example

    Before getting into scheduling a medical test for me, let’s see what happened when I had to schedule a test for someone more important than I am – at least she seems to think she is – my cat, Priss. The comparison between getting tests for Priss and me will be instructive.

    I have a cat, Priss. Priss is pretty chill; here she is thinking deep thoughts:

    2019-02-20 20.39.13

    I take Priss to a local animal hospital, where she is well cared for. I get regular notes and emails telling me when something medical needs to be done for Priss. For example, here’s the header of an email I received last year:

    Priss 0

    Note that the email arrived near the end of August, 2018.

    Here’s the top part of the mail:

    Priss 1

    Note that there’s a picture of a cat in the email – they know who they’re dealing with! They know Priss’s name, and they know she’s a cat, and not one of those friendly but face-licking, slobbering dogs who are incapable of using a civilized thing like a litter box.

    Here’s the rest of the email:

    Priss 2

    They make it hard to miss the phone number or the online scheduling system they support to make an appointment, don’t they? They also spell out exactly what needs to be done. And darn, the email was sent EXACTLY one month, to the day, before the service was due. Please note: this is THEM taking the initiative to follow up, TELLING ME when something needs to be scheduled.

    If this were a human hospital we were talking about, I would say “to make a long story short …” but because this is an efficient, modern animal hospital, I get to say “to tell it like it is …” all I had to do was click on the email, buzz through their easy-to-use on-line scheduling system, make an appointment that worked for them and for Priss, get a confirmation email back right away, and I was done. That’s it!

    On top of it all, the people there are great, and care for Priss really well. There was a problem with her fecal test — results back in a single day — and the treatment was immediate and effective, no more than a day's delay for any step.

    An MRI Scheduling Example

    Now we turn to hospital scheduling for humans, specifically for me at the world-class hospital system, Mount Sinai. I’ve had some medical issues that have required MRI testing. See this for a description of the issue, with details about the testing experience and the conclusions that can reasonably be drawn from it.

    I had  30 days of radiation therapy in early 2018. I was supposed to have MRI’s to see the results of the radiation six months and a year after the treatment. This is standard practice. I know from experience that the grandees at Mount Sinai Medical System haven’t gotten around to sending a team to the Hudson Animal Hospital to learn from their cat scheduling system, so they can put a multi-year project plan in place to implement something similar for their human patients. In a human medical world that worked as well as my local little animal hospital, I would have gotten a reminder a month before my MRI should have been taken.

    Being the patient patient that I am, I waited until after the anniversary itself. Then I sent a friendly reminder to my doctor:

    Gupta 1


    He replied the next morning with a perfectly reasonable response – given that he had to do the work that a vet wouldn’t have had to do.

    Gupta 2


    His prompt reply was Feb 4. I heard nothing for weeks, so I finally reached out again three weeks later:

    Gupta 3


    Again, the doctor in charge of the radiation center, doing clerical work well and promptly, work that he shouldn't have had to do, responded right away:

    Gupta 4

    What happened next? More fun wasting everyone’s time. Remember, with a reasonable on-line system like restaurants and vets have, none of this would be needed!

    A couple days later I got a voice mail, with a friendly person giving me the date and time for which my MRI has been scheduled – of course, without consulting me! I guess I must be sitting around suffering, anxiously waiting for the first possible moment at which I can get my MRI, at which point I’ll drop everything and arrive two hours early. Or not. Even better, this call isn’t from the MRI center, it’s from my doctor’s office, where someone has made an appointment for me, a couple days after the most recent request, weeks after the original one. So I return the call, explain I can’t make the appointed time, and is there any way I could talk with the MRI center and make an appointment myself? Well, she tries to be accommodating, and says it’s OK, but I also need to make a follow-up appointment with the doctor by calling her. I think I can manage this.

    I call the number she gives me, which was the wrong number. I consult the web, and it takes a typically long time to find the center and its phone number for scheduling on the website. Mount Sinai management, it goes without saying, is totally on top of customer feedback and quality management. So they pop up an opinion survey. What happened with the survey is a lesson all by itself in the profound dysfunction of our medical systems in general, and Mount Sinai in particular. I will treat this event in a separate post.

    I call what the website says is the right number, and keeping sarcasm – however warranted it may be – to a minimum here, after a journey through automated VRU’s and other wrong numbers, I eventually get to the person who can schedule me. Sure enough, she finds the order for the MRI in her system, and makes an appointment that actually works for me. Phew! I then, as instructed, call back the main doctor’s office and schedule a visit with him to go over the results, as I had been instructed to do. Please note this visit with the doctor I scheduled; it will start its own little trail of incompetence and waste.

    After way too much effort on everyone’s part, I thought things were finally set. Silly me. I got this call a few days before my MRI appointment:

    Call Mar 14

    After a couple of attempts, I get through. I’m told that the room where the MRI machine is suddenly needs to have major work done, work that apparently couldn’t be scheduled in advance, making the machine itself unavailable. So pick another time. We work something out. I then call the doctor’s office and re-schedule my visit with him, so that it’s suitably after the new date of the test.

    On the morning of the date of my original doctor visit, the one I called and re-scheduled, I get a voicemail saying in effect, “you’re coming into today as scheduled, right?” I admit that the nasty thought of ignoring the call crossed my mind, but my better self took control. I called and got through after a couple tries and explained the re-scheduling. The person verified that the new appointment had in fact been made, but that “someone else” must have failed to cancel the old one. Done. Except that it wasn't really "done." See the associated customer service post to see what happened!

    A week later something came up and I had to move the appointment with the doctor. I called. After explaining what I wanted, the person said, didn’t you just miss a scheduled appointment with the doctor? Nope. Apparently the last person I talked with, whom I told about their mistake, failed to correct it. Again.

    Do you use a calendaring/scheduling system, for example the one in Microsoft Outlook? Have you noticed that you can click on an event and change the date/time, so that it moves to the new time slot? Of course, you can delete the old one and make a new one from scratch if you really want to, but why would you? The evidence seems to point to the possibility that such a feature, which is standard on modern calendar systems, doesn’t exist in the paragon of modern software used by the leading medical system, Mount Sinai.

    Conclusion

    Follow-up of events, both one-time and multiple recurring, is a standard feature of modern scheduling systems. Self-scheduling by software is a widespread feature. It’s widely used, and benefits everyone involved. It’s not as though self-scheduling by software is particularly difficult for medicine. For example, the primary care office I use, OneMedical, has a convenient system that takes account of the length of visit you need, and gives you choices of providers and locations so you can pick what works best for you.  Once scheduling is on-line, it is amenable to serious optimization techniques, which have been deployed with great success resulting in substantial savings and efficiencies in things like infusion centers and operating rooms. This is not possible with the primitive human-phone-based systems in widespread use.

    It’s painfully obvious that the important people at medical centers prefer to spend time doing “important” things at the fancy future end of the innovation spectrum, rather than lowering themselves to implement practical, here-and-now improvements that benefit everyone. When will this change?

     

  • Software is a Pre-Scientific Discipline

    For a wide variety of human-understandable reasons, software is perceived as a science. In academia, it's taught in the Computer Science department, often part of the math department. What could be more precise and scientific than that?

    Whatever its pretensions, software is anything but scientific. It's mostly driven by fashions and fads, led by "experts" who promote theories that sound good when described — but which entirely lack any form of scientific process, testing or evidence.

    Software diseases will continue to severely hamper our computer systems until we wake from our long, pre-scientific sleep. We will know we're making progress when software practices at least to the level medicine had achieved 150 years ago. See these examples: the history of scurvy; the history of bloodletting; Yahoo and Hadoop.

    The Evolution of Science

    Science is not one thing, although the core principles of hypotheses, testing and evidence are always the same. Sciences don't pop up full-grown from nothing. Each field of human endeavor evolves towards being a science (or not) at its own time and pace. There is typically a long gestation period during which resistance is deep and widespread. Physics is a classic example.

    Even when an area of science is well-established, the temptation to simply declare and assert the truth of something without careful proof remains strong and happens all too often. Science is something that human beings do, so it's never "perfect." It's also never "done." The resistance of the entire physics establishment to the now-accepted fact that time changes as the speed of an object approaches the speed of light, and that light has no mass but nonetheless exists and travels at a measurable rate, are classic examples of the fits-and-starts evolution of even the well-established science of physics.

    It was a long, hard slog for medicine to emerge from its pre-scientific state. While there is loads of room for improvement, as I have often pointed out in this blog, medicine has clearly and explicitly embraced scientific discipline in the large majority of its practices, of course with the occasional embarrassing slippage.

    The non-evolution of software towards science

    Let's compare the emergence of powered flight as a science to the methods for building software projects. Here are the key points:

    • Powered flight was widely recognized as important more than 100 years ago. There were widely accepted experts, and the entire establishment gave them money and support. After a couple spectacular failures by the experts, the obscure people who actually figured out how to create a heavier-than-air flying machine got it done, and their methods were soon universally followed. Here is the story in more detail.
    • Building effective software is widely recognized as important today. There are widely accepted experts, whose methods are taught in schools, practiced in all major institutions and mandated by government regulations. After spectacular, repeated failures, everyone says "oh, that's software, what can you do," and moves on. Meanwhile, sometimes obscure people build amazing new software quickly and well most often using unauthorized methods. Their software is widely used and their companies acquired by the big organizations who can't build anything. Nothing changes. Here is an example and details.

    To take another example, while there are many ways that the science of medical drug development could be improved, there is little doubt that it is a scientific venture. In terms of science, in spite of its problems, limitations and inefficiencies, drug development is probably a hundred years ahead of "computer science" in general and software development in particular. See this for a comparison.

    If software were a science

    Think of a list of established principles in software — if software were in fact a science, the things that would be like the basic equations of non-relativistic motion. What's on the list? I suspect it includes things like: Object-oriented programming, comprehensive test automation, architecting for scalability.

    Now think of a list of hot new methods or techniques in software, things that are widely accepted but early in widespread adoption. The list may include, depending on the circles in which you travel, things like micro-services, the Clojure language, Agile methodology with SCRUM, test-driven development.

    Which of the items on either list — your version of the lists, not mine — went through anything like this process:

    There was a bad problem that accepted methods weren't solving. People hypothesized an underlying cause and/or a cure, tested it first on a small scale and then on a larger scale. The evidence was overwhelming in A:B comparison that the cure was effective, so it became accepted.

    Or,

    There were observations that didn't fit existing theories, data that wasn't explained, or discrepancies that couldn't be accounted for. Someone came up with a theory that made sense out of the rogue data. Others formulated the theory exactly and conducted careful experiments; the results were made public, and maybe there was a period of refinement. Finally, the new theory was accepted, because it was experimentally proven to account for all the measured data, something the old theory could not do.

    Anyone with reasonable software experience knows the answer to these simple questions: software doesn't work that way! Not even a little bit! Instead, new practices are invented, promoted and sometimes accepted into common practice. In no case is there a scientific vetting process! People just accept the theory because

    • it makes sense to them, or
    • it's what they've been taught, or
    • it's required by the mandated practice of the group in which they work
    • it somehow advances their career or enhances their prestige

    Sometimes, happily, software fads just fade away for as little reason as they started. A fairly recent example is pair programming, which I describe and examine here.

    In the face of this evidence you may swallow hard and admit that software may not be a science, but it is an established discipline with standards and processes that are widely accepted, as for example you can see in the FDA software regulations. Sadly, that makes it even worse, if it's possible to imagine that. The standards and processes that constitute modern software practice are taken from other fields and jammed onto software. They don't fit and they don't work.

    Conclusion

    No testing. No hypothesis with controlled experiment. No evidence. No process that resembles either medicine (we know there's a problem, we have a possible solution, let's prove it works before using it widely) or physics (we have this data we can't explain, let's propose a theory that accounts for it and run experiments that will prove it right or wrong) or anything else.

    You can say that building software is part of "computer science" until you're blue in the face. You can require CS degrees for your new hires. But the evidence is that software is, without question, pre-scientific.

    We need to at least start building towards a true Science of Software.

     

  • Due Diligence: Financial, Legal and Software

    When you are going to acquire or make a major investment in a company, it makes sense to perform due diligence. Not only does it make sense, it's a fiduciary responsibility! Due diligence on the company's financials are a no-brainer. Same thing with legal. Wouldn't want to be surprised by a landmine in one of the contracts, would you? If there is software involved, most people perform technical due diligence. In each case, you hire an expert who combs through the relevant portion of the company. The expert produces a report, at minimum highlighting any deficiencies.

    They're all pretty similar, right? They're abstruse subjects involving deep expertise where there can be landmines and hidden messes that can have great consequences. That's why you have due diligence.

    Yup, that's the standard view, Due Diligence 1.01. It's even all reasonable … except for Venture Capital investing in tech companies.

    Due Diligence for computer and software technology

    The vast majority of tech due diligence involves fairly large companies with large staffs. When you're looking to do a deal with a fairly large tech company as the target, it's business as usual. You want to make sure everything is done to industry standards. There are probably security and other regulations. Are they in compliance? Are they following industry-standard development methods, or is there some kind of willy-nilly, out-of-control stuff going on? Do they actually have a QA process that assures that new software releases won't go belly-up and hurt the company and its customers?

    This sounds pretty much like legal and financial diligence. Because it is!

    Tech Due Diligence for VC's

    How can a VC responsibly invest in a young software-based startup without understanding the software? Most investors aren’t programmers, after all, and can’t “see” the software. No big deal! VC’s usually aren’t lawyers or accountants either, after all, and there’s a standard solution: hire an expert to perform due diligence. Hire lawyers for all the legal things, accountants to pour over the books, and technology due diligence people to handle the tech. Now that wasn’t much of a problem, was it?

    There's just one little problem: the standard methods for evaluating software lead to terrible results. This shouldn’t be surprising, because the standard methods for building software lead to terrible results! If the industry’s best minds can’t figure out how to build software effectively, why would anyone think that these best minds would be any better at evaluating software and the organizations that create and maintain it?

    You won’t find these industry-leading groups and thinkers wringing their hands or wailing lamentations at their on-going failure – that would be bad for business! So instead, awfulness is accepted as just how things are. So when experts evaluate software groups, the typical process is to compare them to how the vast majority of groups “get things done” – kinda, sorta, eventually, with failures and massive security breaches attributed to some combination of life and the existence of evil criminal masterminds. If the group fails to sing the standard songs and say how wonderful the software dances that are currently in fashion make them feel, then questions are raised.

    Large corporate and government organizations know and accept all this. They take comfort in striving to attain industry-standard “best practices,” and give presentations about how great their direction is. They may put signs up on walls, or hang banners making vague but strong assertions about “innovation” stuff involving the future.

    What if you’re a small organization, a start-up or not much more advanced? For the VC point of view, this makes little difference. They tend to have due diligence providers with solid methods and a track record the partners of the VC firm are comfortable with. This fact of existence leads to a few major behaviors among entrepreneurs:

    • Avoid any VC that wastes your time putting you through what you know to be irrelevant evaluations
    • Hold your nose and go through with it, while trying to gull the evaluating firm into thinking you're more industry-conforming than you are, and to the extent that you're not, you're planning to fix it all up real soon
    • Really change things so that you match industry-standard evaluations, often by hiring a tech leader who's "been there done that."

    Many VC's pride themselves on their judgment of character, and won't take the tech due diligence really seriously anyway — experience has taught them that it's mostly a pile of irrelevant gobbledy-gook anyway. They place their bets on the company leaders, whether they have the vision, drive and smarts to create a winning company, or at least to achieve lift-off.

    This is a real problem, but it logically reflects a larger problem in the tech industry, one that I've tried to articulate in a variety of books and blog posts: there is a huge gap between how the vast majority of software organizations build software and how the most effective small ones build it, not unlike the difference between army draftees just out of basic training and a team of elite Rangers. They both fight, but if made to fight each other, it wouldn't be a "fair" fight. Same thing with software, only even more so.

    The vast armies of software engineers, armed with their impotent and irrelevant Computer Science degrees, resemble draftees out of basic training more than anyone would like to admit. There are so few software Rangers that most of the plodders rarely encounter one. Rangers certainly don't hang out by the water cooler hoping to chat with one of the sloggers — a real Ranger wouldn't want to enter the building, much less be employed there.

    The very best tech due diligence for VC's attempts to differentiate between these cases, which aren't totally distinct:

    1. The company develops software following industry standards.  If what they're doing is amazing and pretty much already baked that could be OK.
    2. The company isn't following standard norms or any other norms. It's just disorganized. This is a problem. There's a risk in whether it can be fixed. Know what you're dealing with is essential.
    3. The group is not following industry norms, but is achieving rapid progress with good quality using non-standard methods — not anything-goes wild-west, but non-standard techniques that are actually methods. There is a wide range here, which must be judged.

    The trouble of course is that standard, off-the-shelf tech due diligence conflates cases 2 and 3 above. Truly effective tech diligence for VC looks for case 3, and judges to what extent the company achieves it.

    Conclusion

    Performing effective tech diligence is pretty similar to financial and legal diligence — unless you're investing in a break-the-rules, innovative startup or young company and you're a VC. In that case, you're best off judging them by different standards than you would normally use. In finance and legal, you're looking to find things that are unusual and diverge from norms — because they could be bad and hurt you. In tech, you're looking for things that strongly differ from standards and norms — specifically methods that trump those standards and norms. You don't want a group that fails to live up to standard army discipline. You want a group that chooses to do things differently — because they do them better, WAY better. That's what makes winners, and that's what VC's want to invest in.

  • An Immutable Distributed Ledger is now in Large-Scale Production!

    First there was Bitcoin, friend of criminals, speculators and tech geeks everywhere. It’s grown amazingly. Then there were alternatives to Bitcoin, often sharing much of the same code, but with different and incompatible tokens. One of those Bitcoin alternatives, Ethereum, introduced the concept of Smart Contracts, which I discuss here. Now, increasing attention is being paid to “blockchain,” said to be the foundation on which crypto-currencies like Bitcoin and Ethereum are built. Large corporations are taking up the charge, places like IBM and Microsoft, and leaders in various industries have projects going to prove out the technology. While the terminology isn’t uniform, it’s easy to see that earlier terms with unsavory associations are being abandoned in favor of more generic terminology, names like blockchain,  “Immutable Distributed Ledger” technology, or just “distributed ledger.”

    Once you start talking about the technology in generic terms, what are the chances of this actually working? At scale? In practical reality? Lots of people in the community of blockchain enthusiasts have expressed concern about this. Legitimate concern. The question naturally arises, but appears not to have been asked, has something like this been built before? Something that could legitimately be called an immutable distributed ledger?

    The answer is a simple “yes.”

    This amazing system, which is one of several in production today, has over 2 billion accounts and over 40 million participating agents. It moves over $10 trillion per year, processing over 150 million transactions a day, and can handle over 50,000 transaction messages per second.

    Let’s dive into the technology a bit:

    • It’s immutable. Once a transaction gets in the system, it can’t be altered or removed. Despite the volumes mentioned above, spread over more than 200 countries, there are no instances of processed transactions being altered.
    • It’s distributed. Computers all over the world are involved. It doesn’t matter where you are: this system enables you to send or receive currency. Even better, currency conversions are built into the system! The distribution has been built in part to enable reliability. While any one computer in the system can fail, the system as a whole has never gone down, and transactions have never been lost.
    • It’s a ledger. It’s a gigantic ledger of currency going into and out of accounts. The ledger balances to the penny every single day.
    • Consumers don’t lose their money! In spite of all the volume, When bad stuff somehow happens, consumers lose nothing. Nada.

    OK, OK, I’ll stop the charade. As you’ve probably guessed, the Distributed Ledger technology I’m describing here is in fact VISA. I’m playing this game because reading about how enthusiasts talk about blockchain, I wonder how many of them know about credit card internals? If they did, they would see that all the goals they have for blockchain have already been achieved in credit cards. And more!

    The key assumption at the core of the blockchain craze is that blockchain is an amazing new technology, a breakthrough that enables all sorts of long-intractable problems to be solved. These virtues are primarily the fact that it’s immutable, it’s distributed and it’s a ledger. Sorry, guys, you don’t need blockchain to build a system that has those attributes. It’s already been built using plain old database technology and secure networking.

    Yes, I played a game when describing the immutable distributed ledger technology that’s already in massive production, knowing everyone would think I was talking about blockchain. But the blockchain groupies are playing a more serious game, convincing themselves and others that blockchain is uniquely able to do things that haven’t been done before, and could never be done without this amazing new invention. Just to be clear, I’m not saying that VISA technology can be applied to the many problems to which blockchain is being applied. I’m simply saying that if you think you have a problem for which an immutable distributed ledger technology is the best solution – that problem can be solved without blockchain, more quickly and with a lot less effort. VISA is just one of many full-scale, in-production examples.

    It's sad that the Blockchain mania is so powerful that no self-respecting executive can risk ignoring it. So all the big banks and even, yes, VISA itself have blockchain based projects underway, nearly all of them involving widespread use of the future tense. I am open to the possibility that some of them may even be deployed in some way, once the people implementing them get realistic and relegate the blockchain technology itself to a tiny, marginal aspect of the project's code base, and realize that everything they're doing could be done better and faster without the distraction of largely irrelevant blockchain. But meanwhile, it's great for reputational enhancement and attention-getting!

    A version of this post was published at Forbes.

  • How We Got Chatbots for Mobile Financial Apps

    Chatbots for financial and other applications aren’t just a cool new thing. They’re a necessity! They solve the worsening problem of too many options to choose from on shrinking screens, with unhelpful help screens.

    Do you access your financial accounts online? If you do, perhaps you’ll remember that the first time you tried to do something, you had the fun of poring over the menu system to find what button to click, sometimes only to reach another screen full of buttons and menus. On the plus side, online financial systems let you get a lot done. On the minus side, jumping through the hoops to actually get them to do what you want can be a long slog. Have you ever gotten frustrated and tried to click on Help? And gotten the long, unhelpful Help stuff? Helped a whole lot, didn’t it?

    Today, nice big screens with high resolution, sitting on a desk somewhere, are used less and less. Cute, portable little screens with phone and camera built in are used more and more, partly because it’s in your pocket, right there when you need it. What happens to all those giant screens packed with menu choices? I guess the designers could have reduced the typeface so much that you’d need a magnifying glass to read them, but they bowed to reality and put just a few menu choices on each screen. Nice to read, but the result is that your multi-screen journey to get to the one you want got even longer. Assuming you remember how to get there. And what if you want something more elaborate, like how close am I getting to hitting my budget for restaurants this month? Fuggedabout it.

    The designers of mobile apps for financial applications aren’t between a rock and a hard place. It’s worse. They’re stuck way back in a long, narrow cave that floods. What to do?

    Echo and Siri have been training us to just ask for things. Who won the game last night? What’s the weather forecast? Even jokes! But banks … now that’s a different matter altogether. Banks are serious things. There’s money involved. Not just any money – MY money!

    So what’s a bank app creator supposed to do?

    It’s actually pretty simple, because there’s not much choice. If you want the bank app to be, you know, USED by the people who have it, you have to make it USABLE. Period. There’s not enough room for menus, except maybe a couple super-popular buttons. Help files? Waste of time. You’re down to one choice: make it so you can TALK (or chat) to the app, and ask it to do stuff for you.

    That’s the logic. Even better, it’s really happening. In real life!

    Bank of America is advertising its chatbot Erica heavily in some parts of the country. The reason is simple: they want their customers to be able to USE the BofA app, not be frustrated by it. There’s the chatbot technology provider Kasisto (Disclosure: Oak HC/FT is an investor) used by multiple banks to power human interactions. The bar has now been raised for financial institutions with apps.

    Let’s review some history. Years ago, what financial institutions had to have was a website for customers to access their accounts. As smartphones spread, the bar was raised: OK, you’ve got a website, but do you have an app? Not having an app was a reason for customers to move to a place that did. Just as most of the financial institutions were breathing sighs of relief that they’ve caught up, the bar is raised again: you mean we have to make the app USABLE? What’s a chatbot, anyway? The pattern here is clear: technology keeps marching along, some financial institution applies it to their customers’ and their own benefit, and the others scramble to catch up. What’s next?

    To find out what’s next, all we have to do is look at the non-financial domains that use chatbots. For example, look at Amazon’s Echo. It started out pretty primitive, but it’s adding capabilities all the time – as Amazon puts it, new “skills.” The bar is already being raised by technology vendors in two specific, technically challenging areas:

    It’s one thing to answer a simple question, like what’s my balance? But real chatting as done by people requires that the chatbot take into account complex questions, context and history.

    A complex question requires doing some real “thinking.” For example, “How much did I spend on eating out last month?” has loads of complexity. The system has to know that “eating out” means spending money on the merchant category “restaurants.”  It’s got to find all those transactions that took place in the month before today’s month, add them up and give you the answer.

    Taking conversation history and context in account is even trickier. Suppose you get the answer to the eating out question. Suppose you now ask “ How about the prior month?” Easy for a human; for a bot, not easy at all! The bot has to figure out that you’re still talking about eating out (restaurants) and that you want the total for a month. It’s also got to figure out that you want not last month, but the one before that. These are the kind of amazing interactions supported by Kasisto.

    Chatbots for financial apps are just being rolled out to solve the otherwise unsolvable problem of screen real estate. Even though we’re still in the early roll-out stages, the next battle is clear. Most of today’s chatbots are in elementary school – soon they’ll need to graduate to middle school!

    A slightly different version of this post originally appeared in Forbes.

  • How Can an Immutable Distributed Ledger have Assets Lost or Stolen?

    As I’ve described, cryptocurrency losses started long ago and have kept on mounting over the years. Most recently, the largest cryptocurrency exchange in Canada, QuadrigaCX,  has experienced a little problem that has resulted in what appears to be a permanent loss of over $130 million for its many customers.

    The losses don’t seem to make any sense. My account is stored in a ledger that’s immutable – it can’t be changed because it’s locked down by unbreakable cryptography. It can’t be lost because the ledger is distributed, so even if a few computers are lost, there are still loads of computers with a copy of my unchangeable account balances in them. So how can it be that I can lose my money? To further increase security, Bitcoin and the other crypto-currencies don’t identify me by my name, but by a really loooong string of letters and numbers. And that’s just the name – to make any changes, someone would need access to my private key. Remember, “private key” isn’t just some password that’s easy to remember and maybe someone could guess – it’s a long number that's part of a proven-unbreakable cryptography scheme, totally guaranteeing that no one but me can access my accounts? It’s impossible for anyone to break through these layers of security, that math guys everywhere calmly assert just can’t be cracked. So what are these losses about???

    The only reason this is mysterious is because the vast majority of stuff we read about Bitcoin, blockchain, distributed ledger technology and the rest is produced by adherents to the new cult. They’re promoters, not evaluators. Let’s start with encryption. Loads of things are encrypted – it’s hardly something that started with Bitcoin. Most sessions with websites are encrypted, as you can see by the https in the URL bar in the browser. I hope you only use encrypted WiFi. Email is encrypted. All databases run by moderately competent professionals are encrypted. And so on. Are websites, email systems and corporate servers hacked in spite of it? You know the answer. People can wave their arms and babble with passion about the power of unbreakable encryption all day long, but bad things happen in spite of it. Is it because encryption is in fact breakable? Nope! It’s because even the biggest castle with the most unbreakable walls has to have doors that are easy to open and close, though which properly authorized people and goods go in and out. Bad guys waltz right into the castle with unbreakable walls through the same easy-to-open doors that all the residents and servants of the castle use! How are those doors locked and guarded? Using absolutely proven, tested, tried-and-true methods such as … user names and passwords! And sometimes even PIN codes on top of it!!

    Oh, no, everyone but everyone talks about how safe and immutable the distributed ledger is – how is it possible for it to be broken, and why are ancient, obsolete things like usernames and passwords involved? It’s simple, really. Say you’re an experienced break-and-entry person. You walk down a block at night. Most of the houses you see have fences, big locked doors and lights on. One of the houses is dark, and its front door is swinging free. Which house do you pick? Everyone scans for opportunities and goes for the weakest point. So no one even tries to break the cryptography – it really IS secure. But what about the place where the long ID and the no-way-can-I-remember-it private key are held? AHA! We’ve gotten to the weak point of the system: the wallet.

    Wallets are just pieces of software that run on your phone, your computer or even online. There are dozens of wallets available. They all claim to store your Bitcoin securely, and maybe they do – except they need to allow a normal human being to actually use them, so they need to be opened by someone a normal human being can handle, like a user name and password! The super-secret but impossible-to-remember private key is stored in the wallet, among other things. Without the private key, you have nothing. If you lose or break the phone that has the wallet, you are screwed. And of course if your phone or computer is hacked, someone else will immediately transfer your Bitcoin out of your account into theirs. There is no recourse. None. Think that never happens? It’s been going on for years, see this. A 20-year-old college kid was just sentenced to 10 years in prison for stealing more than $5 million by phone hacking, see this. That was a first-ever case – usually, no one is caught.

    Some people, concerned about the security of their wallets, have turned to professionally-managed exchanges, which both store crypto-currency and enable it to be converted and transferred in and out. An example of such a company is Quadriga, which was the largest such exchange in Canada last year. Now it has made various court filings, and is unable to return its customer’s roughly $200 million in assets, see this. Why? Because those assets were held in a wallet on the now-deceased founder’s laptop computer, and no one can get into the computer – its contents are encrypted and the access information was last seen somewhere in what was the founder’s brain.

    Yes, the distributed ledger is secure and immutable. Yes, the cryptography used is in fact unbreakable. Most descriptions stop there, leading you to think you’re protected against loss or theft. As I hope is now clear, Bitcoin and its numerous offshoots do indeed involve some amazing technology, as I’ve described here. But that doesn’t mean that it’s any more secure or protected against loss than any other software. Because of its immaturity, it is proving to be more vulnerable to loss and theft than “normal” money. And the non-monetary blockchain solutions are just as vulnerable.

    This post originally appeared on Forbes.

  • If You Like Private Blockchain, You Should Also Like Living in a Tent Instead of a House

    Bitcoin is an amazing technology. I admire it. The central idea of how to implement a virtual currency with no one in charge, but where the “bank vault” is nonetheless pretty safe, is clever, as I explained here. However, the second you take this clever idea and apply it to situations for which it was not designed, it quickly becomes ridiculous – inferior by factors of thousands compared to existing solutions. It’s as though you liked hiking and camping in a tent — and went back to your home on your suburban block, knocked your house down, disconnected from electricity, municipal water and sewer, stopped garbage collection, sold your car and bicycle, and gloried in your new, improved way of living during cold winter nights. Good idea, but wrong place, and there's probably a reason few people choose to live that way.

    As a start for understanding why private blockchain is a ridiculous notion, let’s imagine that we all live in buildings with municipal water supply, and that suddenly someone decided it would be cool to live “off the grid” in a dry area where it does rain, but infrequently. How are you going to get and store the water you need to live? Obviously, you have to somehow make maximum use of the rare rainfall that happens. You construct as wide and varied a system of rain-catchers as you can. If you have a house with a roof, you arrange the gutters to go to downspouts to rain barrels. You carefully construct the rain barrels so they don’t leak, since water is precious, after all – the rain barrels have to be “immutable.” You also stretch out any canvas or anything else you can scrounge up to capture the rain before it hits the ground, and route it to barrels. You construct a set of pipes to connect the barrels, to make sure that all the barrels have water, and none has too much. You end up with a distributed set of barrels, each containing the precious water you need to collect and preserve. The system is even more impressive when it supplies a small encampment of people, with pipes distributing the water among the barrels, assuring that everyone has enough water.

     

    Anyone wandering in the wilderness who encountered this maze of connected, distributed, immutable barrels and rain catchers would be impressed at what a good solution it was to the problem of having enough water when there’s no municipal water supply. Someone might come out to the place, take lots of pictures and blog about it. It might catch on, and some homeowners with regular water supply might be attracted to the notion of being ready to survive when civilization collapses and everyone will be forced to live off the grid. Most people, of course, will be happy to continue enjoying normal hot and cold running water, available by turning the faucet.

    The Bitcoin solution was specifically designed when you really don’t want a municipal currency authority. Like the distributed water catchers and barrels, it’s a clever solution for exactly that problem. What happens when you decide it’s OK after all to have someone in charge – you’re not in the desert, you’re not a survivalist, and you just want a convenient water supply? What kind of sense does it make to somehow get a private corporation to be completely in charge of the system of water catchers, pipes and barrels in a place where connection to central water is readily available? Do you think the new system would be less expensive, more convenient and less obtrusive? Do you think the privately run immutable distributed water system, with all its barrels, catchers and pipes would be able to handle sudden demands like filling your pool or even a few houses running their lawn sprinkling systems at the same time?

    That’s exactly what’s happening with private blockchain implementations. Every single vendor that so enthusiastically promotes its private blockchain tells you quietly what’s wrong, things like the transaction rate is worse by factors of thousands compared to normal DBMS’s (of course they don’t put it that way), and a host of other deficiencies that they’re overcoming … by step-by-step adapting standard database techniques first deployed decades ago and by now standard methods, and making an “improved” private blockchain. Improved, but still dramatically worse by all measures compared to standard technology.

    Blockchain is a pile of new software that was designed to solve a very special problem that does not occur in normal life. Private blockchain is an attempt to take that highly unique solution, designed for wilderness living with no central authority in charge, and apply it to normal urban/suburban life with a central authority. The amazing, cool and different things about blockchain were invented specifically to solve the problem of having no central authority. The second you introduce a central authority, i.e., make it a private blockchain, all those special things that make blockchain unique suddenly become huge impediments, obstacles with no redeeming virtues.  It makes as much sense as camping out in your suburban back yard — OK if you're a kid or want to give your tent a dry run, but nothing any sane person would think is an improved way of living.

    This post originally appeared on Forbes.

  • Are Blockchain Smart Contracts Smart? Are They Contracts?

    Smart contracts are all the rage in the blockchain world these days. They are the key feature that has pushed Ethereum to prominence. They’re everywhere!

    There are just a few little problems. They’re not smart. They’re not contracts. They’re rife with security issues. And they violate the core principles that are supposed to make blockchain wonderful. Other than that, they’re great!

    There is a huge amount of rhetoric and propaganda about what Smart Contracts are supposed to be. Here’s the reality: A smart contract is a software program. It’s written in one of a variety of mostly brand-new languages, chief among them Solidity. A smart contract is the exact equivalent in the blockchain world of a “stored procedure” in the database world; this means that it’s embedded in the blockchain and has access to its internal functions.

    At first glance, smart contracts can seem like a clever idea that enables endless extensions to the underlying “immutable distributed ledger” technology in which they’re embedded, greatly extending their flexibility and fields of application. Let’s take a look at how this first glance holds up under scrutiny.

    Here’s a typical explanation of smart contract:

    “Here’s a very reductive way of establishing a smart contract: let’s say you and I have agreed that if I write you a history of bitcoin, you’ll send me $10 on my birthday this year. We can do that via a legally enforceable contract, which involves lawyers, notaries, and so on — or we can do it via Ethereum. In the latter case, you put $10 worth of smart coins in escrow, and when the terms of the contract are met, those coins are released to me. If I don’t meet the terms of our agreement, the coins are released back to you.”

    The key, innocent-sounding phrase in the above description is “when the terms of the contract are met.” When I write you a history of bitcoin, will you accept it if it’s a piece of crap? Probably not. Here’s what has to happen with the deal:

    • We have to agree on the terms of the deal
      • This happens verbally, no matter what mechanism is used.
    • We have to express the deal terms in a mutually acceptable way.
      • In the land of normalcy, either our verbal agreement would be OK, or we’d have an email or paper exchange.
      • In smart-contract-land, someone would have to write a program in an acceptable language such as Solidity. We would both have to have wallets and accounts in the same crypto-currency among the hundreds that are out there. We would have to agree that the Solidity program expressed our mutual agreement. How good are your Solidity reading and writing skills? You would also have to deposit $10 in your account.
    • I would write up my history and send it to you
      • In real life, I’d get it to you using paper or email.
      • In smart-contract-land, there is no good way to send an email – and putting an email address into a smart contract would make it available to the public! There are some clever hacks involving external services that monitor accounts in the blockchain, but there’s no direct solution. So I’d have to get my history to you using plain old real-life methods.
    • A decision would be made about whether the history I send satisfied the contract.
      • This would be done in real life by you reading the history and making a judgment.
      • Smart-contracts would remain blissfully unaware of this crucial step, unless and until an amazing advance in AI/NLP is somehow embodied in them.
    • If the terms of the contract are met, the money would be sent to me.
      • In real life, you’d hand me the $10, mail it to me, or electronically transfer it to me via one of the widely available methods, for example Venmo, which handled over $12 billion in transactions in 2018.
      • In smart-contract land, you’ve had $10 tied up in your crypto account since the contract was agreed to and the program – oops, I meant the “smart contract” – was created by one or both of us. You would then send a transaction to the contract to transfer the money to my account, after which I could convert it to normal money, with fees taken out along the way.

    Someone please explain to me how using a smart contract to embody and execute our agreement is an improvement on normalcy?

    In addition to the problems mentioned along the way, we’ve got these:

    • If you love my history but want to cheat and not pay me, how does the smart contract help?
    • If I’m worried about you paying me and want an enforceable contract, how does the smart contract help?
    • If we make a written agreement, even a simple email one, at least we can probably both understand it. What are the chances that we are both fluent in Solidity?
    • Assuming we somehow manage to write the code in some language, what if we’re less than perfect and have a bug in the code? The teensy weensy little problem with smart contracts is … they’re immutable (i.e., can’t be changed), along with the blockchain in which they’re stored!
    • The key part of any agreement of this kind is the characterization of the history I’m supposed to write and the acceptance criteria. How can that be expressed or evaluated in lines of code?
    • In terms of just moving the money quick and easy with minimal overhead, how is anything in crypto-land easier or better in any way than Venmo?

    Smart contracts are a really cool idea. The best way to use them is in a sandbox where really smart, unemployed people can play games and make experiments, keeping them out of trouble and far away from real life and real problems that need to be solved.

    This post originally appeared in Forbes.

  • Nobody Cares about Data

    Nearly everyone professes to LOVE data. Just think about all the talk about Big Data, Data Lakes and the rest. Lies. Liars lying big LIES. Everyone says they like data … until they get near it. Suddenly they develop fevers and rashes. They're allergic! Someone else will have to actually handle the data!

    Data, the foundation of AI, ML, Analytics

    All you have to do is get a job in one of these fancy subjects, and you quickly get hit with reality. When you were in school, you had wonderful exercises where you could develop your skills in deep learning, random forest, or whatever. Now in the real world, some older person assigns you to some juicy-sounding task where you'll get to use your skills. Where's the data? you ask. A wrist-wave of the hand tells you it's over there. You go over there and can't believe what you see. Why, it's nothing like it was in school! You try for a couple hours to clean things up. Then a couple days. It's still bad, but maybe good enough. So you run it through some models. Disaster. The system crashes and/or generates garbage. You complain. "Grow up," you're told. "This is what we've got to work with. Deal with it."

    At the end of a year, you realize you've spent half your time in meetings of one kind or another, and 90% of the "working" time has been spent trying to get the data in order. With unsatisfying results. You've got some choices to make. You can lie. You can get into management, marketing or sales. You can roll up your sleeves, forget the fancy stuff you learned in school, and become a data clean-up specialist, which is actually more like a create-decent-data-from-scratch specialist. Which is NOT what you signed up for. Waaaaahhhhh.

    What's maybe worse of all is the status. AI and machine learning are clearly the prestigious upper floors of a grand apartment building. Deep learning thinks it's the penthouse, but whatever. The lower floors are occupied by simple analytics. The ground floors are occupied by people managing the databases and Hadoop clusters, and maybe even some ETL tools.

    And then there are the basements. The sub-basement where the garbage chutes end. Where the janitors live. Where the crap from the elegant apartments is taken to be discarded. Where the water and oil and natural gas enter the building — the things the fancy people on the upper floors need to wash up, keep warm and prepare to dress elegantly. That's the floor … and the status … of the data specialists. 

    You can tell yourself until you're blue in the face that without good data, none of the fancy stuff would work. It's the foundation, dammit! The janitors probably tell themselves the same thing about the heat, cooling, hot and cold water, cleaning and garbage removal. True — but they're still janitors, wearing a uniform and passed in the halls by the upper-floor people as though they don't exist. 

    Bad data equals bad results

    There's a simple reason why the incredible potential of the Big Data movement has now morphed into AI/ML and is even incorporating Blockchain. The time passes, tick. Tick. Tick. Tick. No results! Uniform use of the future tense! Claimed successes aren't really, when you dig into them.

    Some of the reason is typical organizational incompetence. But much is also due to the fact that we are swimming in a sea of big data and no one wants to clean it up! It's so bad, we mostly don't acknowledge it; much easier just to ignore it.

    This problem isn't new. See this:

    11

    I've talked about the importance of data as the foundation of AI/ML here. I've illustrated the horrendous problem of bad medical data here. Even basic data, like what providers are where, is wrong too often. By the way, these illustrations should be considered informal tips of massive icebergs. When I talk with true experts who are themselves knee-deep in this stuff, I find the situation is … even worse.

    As today's illustration of the problem, let me show you a piece of mail I got. It's from a major corporation, one of the big regional cable companies and internet service providers. They've got decades of experience working with customers in their geography. They've got to know every address, every household, with complete histories of using their service, dropping it, signing up again. How could they not know the basic demographics and the kind of approaches that work and the ones that don't?

    Here's the mail I got (I blocked out the street number):

    JO Black Optimum ad

    Looks OK, right? Nice and clear. Specific to the town, so it feels personal. Lots of good things about it. They even designed the envelope so you could see the plastic card on the right, with an eye-catching banner over it.

    There's just one little problem. JO Black died in May 2001. More than seventeen years ago.

    I don't think there's anything else I need to say except, good job, Optimum! You're doing a great job illustrating the near-universal toxic, rotten ocean of data in which we swim, and doing your part in keeping it that way.

    Wait, you might say, this is a trivial little problem. In a way, it is: one piece of mail that shouldn't have been sent. But it's an illustration of a problem that's broad and deep. The notion that a wrongly sent piece of mail "means nothing, is trivial" is an attitude that is EXACTLY why people who care about data metaphorically wear uniforms and work out of the basement. Maybe Optimum is worse than all the rest. Sorry, they're not. JO Black gets a VERY slowly diminishing stream of mail at this address from a wide variety of vendors, large and small. So does Mrs. Grace Black, who died 4 years ago. So does Ms. Jessica Black, who lived here for awhile before moving 20 years ago. So do Mr. Samuel Black and Ms. Elspeth Black, who never lived at this address.

    The Problem is Everywhere

    To be totally clear: the problem isn't just wasteful mail solicitations. It's everywhere, and every stage of data collection and utilization. The problem with healthcare data is immense, for example, as I've illustrated often. Bad healthcare data, which is ubiquitous, has the direct result that normal, innocent people needlessly suffer and die. It doesn't get better, because all the smart people and the important decision-makers are busy attending conferences about how AI is transforming medicine and how blockchain will solve all the medical data problems — leaving the ragged crew of people who are supposed to fix the problem ignored in the dank basement, spending their time scheming how they can at least get to the first floor, since it's perfectly obvious that no one is actually interested in … fixing the data problem!!!

    Conclusion

    Everybody says they want data. BIG data. But what they really want is a springboard to do something prestigious, which turning a toxic stream of severely polluted data into something textbook-clean is not. While hardly the only factor, this is a major factor in the widespread untalked-about failures of fancy modern techniques to deliver practical results. The plain fact is, nobody cares about data.

  • The Hierarchy of Software Skills and Status in Data Science

    There is a striking hierarchy of skills in software, as I've explained here. When you dive into any particular aspect of software, you usually find that it's got a hierarchy all its own. Data science is a subject of intense interest these days, so in this post I'll explain some of the basics of the data science skills hierarchy.

    A skills hierarchy is very much an insider's game. What most people care about is status. I talk about the basics of software status here. Remember, the skills hierarchy is a whole world away from the status hierarchy that most people care about. Don't confuse the two!

    Data Science skills

    First and foremost, it's important to understand the incredibly broad range of subjects covered  by the term "data science." I attempt to explain the basics of the range in this blog post. You can be just amazing in one of those subjects, while being a neophyte in one that the outside world may consider to be "related," but which in practice is not just down the hall, but in a different building on a different campus.The general understanding of this range is SO pathetic that "data science" is typically managed as a completely independent, free-standing group. Which makes about as much sense as believing that a sous-chef belongs in something that isn't a kitchen. Or that everything that everyone does in a kitchen is basically the same thing.

    Here's one cut at the hierarchy in data science, starting from the base:

    1. Tool users.These are people who have learned how to use some software tool, or maybe a couple. Most "data scientists" fall into this category.
      • They don’t understand how the tools are built or any of the underlying software
      • They may know their tool, but aren't real clear on what the other tools are about, much less when you might consider using one.
    2. Some have broader knowledge of tools
    3. Very few have the sophistication to understand real data analysis, per my series of AI/ML; see this and the links in it: https://blackliszt.com/2018/04/getting-results-from-ml-and-ai-3-closed-loop.html
    4. Of those, even fewer can understand the underlying algorithms and follow the latest research literature
    5. Of those, even fewer can make real algorithmic advances and implement them as tools and deliver practical value.
    6. Of anyone who can do all of the above, it is rare to meet anyone who can address and solve deep tool-level problems in other domains needed to make their code practical in the real world.
    7. Finally, it is extremely rare to meet people who, in addition to their deep and broad prowess in data science and relevant skills needed to make it real-world practical, have similarly deep skills in an associated domain needed to make the data science fully effective for a business.

    The issues of this hierarchy are compounded by the usual over-selling by people who are good promoters but little else, and corporate/government big-wigs who don't want to be bothered with details, but are keen to be seen as "doing something" on such a high-visibility topic. Getting results that make a difference is pretty low on the typical priority list.

    And then of course there are the "data scientists" themselves, who most often are sincere people who are trying to do a good job as they've been taught to do it — mostly by professors and others who have no idea what real-world success looks like, much less how to bring it about.

    Finally, there is the usual "manage something that's invisible to you" phenomenon I have often discussed in this blog, which leads to so much dysfunction and so many wonderful Dilbert cartoons.

    Conclusion

    People talk as though "data science" were a thing, with the usual kind of hierarchy based on level of management and/or "experience." Those typical patterns of hierarchy just don't cut it for understanding what's going on in data science, just like they don't cut it for understanding software development. We will continue to see waste and dead-end efforts until we at least make a start at making our understanding of data science more sophisticated, and aligned with the facts on the ground.

  • What Software Experts think about Blood-letting

    Software experts do NOT think about blood-letting. But ALL medical doctors thought about blood-letting and considered it a standard and necessary part of medical practice until well into the 1800's. They continued to weaken and kill patients with this destructive "therapy," even as the evidence against it piled high.

    The vast majority of software experts strongly resemble medical doctors from those earlier times. The evidence is overwhelming that the "cures" they promote make things worse, but since all the software doctors give nearly the same horrible advice, things continue.

    Blood-letting

    Blood-letting is now a thoroughly discredited practice. But it was standard, universally-accepted practice for thousands of years. Here is blood-letting on a Grecian urn:

    11

    Consider, for example, the death of George Washington, a healthy man of 68 when he died.

    GW death

    Washington rode his horse around his estate in freezing rain for 5 hours. He got a sore throat. The next day he rode again through snow to mark trees he wanted cut down. He woke early in the morning the next day, having trouble breathing and a sore throat. Leaving out the details, by the time of his death, after treatment by multiple doctors, about half the blood in his body had been purposely bled in attempt to "cure" him of his sickness!!! If he hadn't been sick before, losing half the blood in his body would have killed him.

    If you are at an accident and you or someone else is bleeding badly, what do you do? You stop the bleeding, because if you don't, the person will bleed to death. That's now. Then? You bleed the sick person because it's the universally accepted CURE for a wide variety of sicknesses.

    Bloodletting was first disproved by William Harvey in 1628. It had no effect. It remained the primary treatment for over 100 diseases. Leaches were a good way to keep the blood flowing. France imported over 40 million leaches a year for medicinal purposes in the 1830's, and England imported over 6 million leaches from France in the next decade.

    While blood-letting faded in the rest of the 1800's, it was still practiced widely, and recommended in some medical textbooks in the early 1900's. We are reminded of it today by the poles on barber shops — the red was for blood and the white for bandages; barbers were the surgeons who did the cutting prescribed by doctors.

    Blood-letting in software

    By any reasonable criteria, software is at the state medicine was in 1799, when everyone, all the experts, agreed that removing half the blood from George Washington's body was the best way to cure him.

    If you think this is an extreme statement, you either don't have broad exposure to the facts on the ground or you haven't thought about what is taken to be "knowledge" in software compared to other fields.

    I hope we all know and accept that the vast majority of what we learn and come to believe is based on authority and general acceptance. This is true in all walks of life. Of course not everyone believes the same thing — there are different groups to which you may belong that have widely varying belief systems. But if you're somehow a member of a group, chances are very high that you accept most things that most members of that group believes.

    This is no less true in science-based fields than others. The difficulty of changing widely-held beliefs in science has been deeply studied, and the resistance to change is strong. See for a start The Structure of Scientific Revolutions. I have described this resistance in medical-related subjects, and in particular showed how the history of scurvy parallels software development methods all too well.

    But at least, to its great credit, medicine has gone through the painful transition to demanding facts, trials and real evidence to show that a method does what it's supposed to do, without awful side-effects. That's why we hear about evidence-based medicine, for example, while there is no such thing in software!

    I hear from highly-qualified and experienced software CTO's that they are going to lead a transition of their code base so it conforms to some modern cool fashion. One of the strong trends this year has been the drive to convert a "monolithic code base" (presumed to be a bad thing) to a "micro-service-based architecture." When I ask "why" the initial response ranges from surprise to a blank stare — they never get such a question! It's always smiling and nodding — my, that CTO is with-it, no question about it.

    Eventually I get the typical list of virtues, including things like "we've got a monolithic code base and have to do something about it" and "we've got to be more scalable," none of which solves problems for the company. When I press further, it becomes obvious that the CTO has ZERO evidence in favor of what will be a huge and consequential investment, and has never seriously considered the alternatives.

    As is typical in cases like this, when you scan the web, you see all sorts of laudatory paeans to the micro-service thing, very little against it. Most important, you find not a shred of evidence! No double-blind experiments! No evidence of any kind! No science of any kind! What you also don't find is stories of places that have embarked on the micro-service journey and discovered by experience all the problems no one talks about, all the problems it's supposed to solve but doesn't, and the all-too-frequent declarations of success accompanied by a quiet wind-down of the effort and moving on to happier subjects. Because of my position working with many innovative companies, this is exactly the kind of thing I do hear about — quietly.

    Conclusion

    We've got a long way to go in software. While software experts don't wear white coats, the way they dress, act and talk exudes the authority of 19th century doctors, dishing out impressive-sounding advice that is meekly accepted by the recipients as best practice. No one dares question the advice, and the few who demand explanations generally just accept the meaningless string of words that usually result — empty of evidence of any kind. It's just as well; the evidence largely consists of "everyone does it, it's standard practice." And that's true!

    Software experts don't think about blood-letting. But they regularly practice the modern equivalent of it in software, and have yet to make the painful but necessary transition to scientific, evidence-based practice.

     

  • Apple’s Facetime Problems Illustrate What’s Wrong with Blockchain

    Apple’s had a rough time recently, with bugs, security problems and sales issues. The recent Facetime bug is particularly embarrassing. It’s made the news! There are stories about it all over. Apple is scrambling to fix the issue and end the pain and embarrassment, pronto.

    Blockchain has also had a rough time, with recent cavernous losses that extend a years-long pattern. Blockchain enthusiasts march on, seemingly oblivious to the intractable problems that cripple their beloved technology. So far as anyone can tell, no one is scrambling to fix the problems.

    Comparing the two situations is interesting and educational.

    The Apple bug was first discovered by a teenager while he was setting up a Facetime group chat.

    • Most blockchain problems are discovered sometime after a substantial loss has taken place, when you go to check your account and are shocked to find it has a whole lot less value than it had last time you checked.

    The boy and his mom were frustrated by how hard it was to get through to anyone at Apple to report the bug. They were doing the right thing, while Apple was being a typical lumbering, unresponsive bureaucracy.

    • You discover the loss in your crypto account. You’re upset. Who do you call? Where’s the 800 number for customer support? If you didn’t know it already, you quickly discover that there’s no number, no one to call. There’s no organization in charge at all! And in those cases where there sort of is, they refuse to fix the problem.

    In less than a week, Apple officials woke up to the fact that they had a problem. A big, ugly, embarrassing one. To their credit, they did two things.

    • In some of the most important cases, such as Bitcoin, there is literally no one in charge – that’s the whole point of Bitcoin – it’s a system that was designed to have no one in charge. It’s brilliant, as I describe here. But it’s also fatal when the system is hacked.
    • In other cases, such as exchanges, there is someone in charge. But their typical response is to claim, with good justification, that “fixing” the problem would destroy the fabric of blockchain. And after all, in many important cases, the funds have long since been converted to cash and are long gone – how can that be “fixed” without catching the bad guys? And as I’ve described, while bad guys in normal banking are often caught, in the crypto-currency world, they almost never are. So your money is gone. Gone!

    The first thing Apple did was shut down their servers so that group Facetime was no longer possible. This didn’t happen all at once, but rolled through the system pretty quickly.

    • Immediate action to fix the problem in blockchain? Doesn’t happen.

    The second thing Apple did was announce that the bug would be fixed and released in about a week.

    • Here’s where it gets really bad for blockchain: where’s the bug that can be fixed to solve the underlying problem? No one can say! So far as all the blockchain “experts” are concerned, there is no problem to be fixed. The silence is deafening. When have you ever read about any kind of crypto-currency loss, after which someone “in charge” said something like: “the loss was due to [this bug}, which we’ve found and fixed and will be effective on [this date]”? Anyone?
    • When the responsible problem is in a so-called smart contract, it’s even worse. Smart contracts are stored in the immutable blockchain itself, and so, unlike normal programs, can’t be fixed or changed in any way. The geniuses who invented and support smart contracts consider this fatal flaw to be one of their great advantages. Go figure.

    The net effect of the Apple bug is that the privacy of certain Facetime users was compromised. Embarrassing. Bad. But your wallet is unaffected. But at least the news got out quickly, people can avoid the feature for a bit and then go back to using it, should they choose.

    • The net effect of the myriad of Crypto and blockchain bugs and hacks is loss of the equivalent of real money, sometimes to the tune of tens of millions of dollars. The only way to avoid the problem is to get out of crypto. Totally. And never go back.

    The contrast between the Apple Facetime bug and the various crypto/blockchain bugs and hacks couldn’t be more stark. With Apple, there’s someone in charge; the someone wakes up to the problem within days, and moves decisively to first block the problem and then fix it. In blockchain, there’s no one in charge (by design!); the affected people wake up to their problem, whine about their often substantial financial loss, but are largely ignored by the community of experts and operators, who soldier on, promoting the wonders of the amazing immutable distributed ledger technology.

    Here’s my prediction: the blockchain mania will continue to spread for a while, but then will slowly fade away, with few of the promoters admitting their lapse in judgment. As with most technology fads, everyone’s attention will simply shift to something shinier and newer as the problems grow too large to be ignored. There's a long shot there will be some shining successes with blockchain — but I predict that when you look under the covers, it won't really be blockchain doing most of the work.

    (Disclosure: While I’ve read API’s and source code, I’ve never owned cryptocurrency of any kind, and don’t plan to any time soon.)

    This post originally appeared on Forbes.

  • Crypto-currency Hacks and Losses Mount While Supporters Remain Silent

    Insiders most like to describe Blockchain as Immutable Distributed Ledger technology. They love that it’s distributed, and a “ledger” rather than a database. But most of all, they seem to like that it’s “immutable.” To enthusiasts, this means that the unbreakable cryptography and other techno-nerd elements result in impregnable, hack-proof software. In a world filled with crappy software that’s thoroughly “mutable,” hackable, breakable and a smorgasbord of other criminal, consumer-hurting things, this is a wonderful thing. No wonder so many people and corporations are jumping on the Blockchain Bandwagon. The smell of FOMO (Fear Of Missing Out) fills the air.

    The FOMO is really strong on Blockchain. So strong that it appears to prevent enthusiasts from paying attention to the fact that has been established over the last few years: Blockchain may indeed be Distributed and a Ledger (more on those in subsequent posts), but it’s hardly immutable. In fact, it’s just as hackable as any other piece of software – even more so because no one’s in charge of keeping it safe!

    The latest loss is small by comparison to some of the earlier ones. The one announced on January 8, 2019 amounts to “just” $200,000 worth of ethereum classic. What’s worse is that the attack was at the core of  the blockchain. Apparently the attack was carried out by miners, the servers that are at the core of blockchain’s operations and security, the ones that perform the magic cryptography that supposedly prevents bad things from happening. The hack itself involved the absolutely worst thing that can happen to a crypto-currency – about 40,000 ETC was double-spent.

    If this were the first loss, I would understand the blockchain folks minimizing its importance. It’s hardly the first loss. Who talks about the Mt. Gox hack, in which nearly half a BILLION dollars was lost? That happened about 5 years ago! Mt. Gox has been followed by an un-ending stream of other successful (for the criminals) attacks and losses. One of the more famous was the $50 million lost in the DAO hack. Less famous hacks resulting in losses over $10 million took place in 2018. The pattern of criminal success shows no signs of slowing down.

    How can any sane person continue to back blockchain as a transforming technology due (in part) to its immutability and implied greater security in the face of this evidence? Obviously, what’s happening is that people are simply ignoring the evidence. That’s it!

    Let’s put this in context. What would the stories be if anything comparable took place with plain old banks, with their supposedly obsolete software and security that’s primitive by comparison? While lots of normal banks are robbed every year, these are small-scale occurrences, and many of the perpetrators are caught. For example, here is the FBI’s latest news about bank robberies. You’ll see that there are loads of convictions and prison sentences. Here is a story from December 2018 about a man who robbed a local bank of $536 in order to pay his rent. He has just been sentenced to 46 months in prison.

    Are there bank robberies in which large amounts are stolen? Check out the list of them in Wikipedia. The list goes back more than a century. The largest robberies don’t come close to the criminals of the blockchain world. The most recent one listed was 20 years ago, when the Bank of America was robbed of less than $2 million. Peanuts!

    OK, you might say, but what about cyber-crime? There’s actually quite a bit of it. But digging into the exact nature of the crimes and how they’re committed is quite interesting. It may exist, but I couldn’t find ANY cases of the core bank systems being hacked. And NONE of the central database (the equivalent of blockchain)! In every case I’ve seen, it was plain old systems network hacking and/or criminal employees that were the problem. Yes, some large amounts were involved, for example in the Bangladesh robbery. But in that case as in many others, corrupted insiders were involved. It had nothing to do with the security of the banking software itself!

    If normal banks had been hacked the way blockchain has been hacked, you’d find that the core banking system itself was breached, or the central database itself. In no case that I can find has this happened. What this means is that blockchain, in its short existence and with its relatively tiny fraction of money, has been hacked more successfully and more deeply than any normal banking software has been. “Immutable,” huh? Explain that again, please. But stick to the facts this time.

    The conclusions we can draw from these facts are simple, clear, and hard to dispute:

    • Blockchain is highly susceptible to being hacked in a wide variety of ways.
      • This has been demonstrated by events for more than 5 years; the hacks are on-going.
      • Large amounts of money are lost in the hacks.
      • The hackers aren't caught, much less punished.
    • While there are lots of physical robberies of old-style banks, the amounts involved are small, the perpetrators are often caught, and consumers are not hurt.
    • While there are hacks on old-style banks, they have had little success in US banks, and the same kind of cyber-security breaches that occur everywhere are involved.
      • In no case have the hacks been as deep in the software as many attacks on blockchain have been.

    There's lots more that could be said about this, but here's the bottom line: if you want to keep your money safe, put it in a traditional bank, whose software systems are indeed immutable. Any blockchain storage is more susceptible to attack and loss than the software used by traditional banks.

    This post originally appeared at Forbes.

  • The Novel Idea at the Heart of Bitcoin

    There aren’t many true and surprising new things in software technology, in spite of all the gushing about new stuff. At the center of Bitcoin is a tech advance. Not a minor step forward. Not an enhancement fueled by faster chips. An amazing idea that is the engine that has fueled its explosive growth. It’s not something people talk much about, sadly. They should. The core of the idea is the miners that are the heart of the Bitcoin engine.

    If you’ve heard anything about Bitcoin, you’ve probably heard that it’s a crypto-currency. You’ve heard it’s totally secure because lots of computing locks the data in an air-tight vault secured by the latest cryptology algorithms. You’ve heard that it’s a ledger of transactions, and that the ledger is distributed, which somehow makes it better. All these things that you’ve heard are correct – and it’s the miners at the heart of every one of those true things.

    First, let’s step back a minute and understand the problem that Bitcoin solves. Bitcoin isn’t cool in the abstract – it’s cool because it’s a creative solution to a really hard problem. The problem, in a nutshell, is to create a currency, like US dollars or Euros, that isn’t controlled by any central authority. That’s a HARD problem. How can you have a currency that people accept with no one to issue it? If it’s somehow issued, who’s going to do the work of creating and managing it?

    Long ago, currency consisted of fairly scarce, valuable objects, like sea shells. Then, precious metals were used. Since it was hard to judge how valuable a piece of metal was, people in authority created standard sizes, shapes and values – today’s coins. Then paper money was issued by early banks, with the precious metals in the banks backing it up. Central government authorities then replaced the banks, and currency became a per-country thing. Finally, it became detached from the coins, a.k.a. “the gold standard.” That’s where we are today, with huge government authorities issuing and controlling abstract and paper currency at will, manipulating it to meet political goals. The problem at the heart of Bitcoin is, how can you create an abstract currency that people can trust without a central authority of any kind, much less a government? I trust you’ll agree, that’s a truly hard problem.

    Before diving into the solution to this problem, it’s worth understanding why it’s a problem. The core issue is the money supply, and how central authorities manipulate it to implement monetary policy in various ways, shifting with the political winds. Central bankers can print more money, take money out of circulation, raise and lower interest rates and do other things on a whim. Other branches of the government closely monitor who does what with their money via extensive, ever-growing, onerous regulations that make everything harder, slower and more expensive. How can we get out of this? How can we escape the armies of faceless bureaucrats who control the money and watch what we do with it?

    The solution has to somehow make everything work with no one in charge. Get people to do lots of work and spend lots of normal money to create and maintain a robust system of virtual currency, and somehow get those people to be absolutely incorruptible?! They’ll be in charge, but not tempted even a little to use their power to enrich themselves? How is THAT supposed to happen??

    That, my friends, is the genius of Bitcoin. The genius is embodied in the design of the miners.

    Miners are volunteers. No one selects them – they just step up, get their hardware and software together, and start mining. All on their own – without permission and without even an invitation! Here’s the key part: when you mine, you make money, in the form of newly-issued Bitcoin. The formula and the rules are built into the software that everyone uses. When you mine, you make money. The more you mine, the more you make. If you’re ever tempted to think about fiddling with the software, cheating and just taking a bunch of money (Bitcoin), you immediately think of the huge investment you’ve made in mining equipment, which isn’t good for much of anything except mining. If people started thinking that miners were self-dealing corruptocrats, the value of Bitcoin would immediately plummet, and the miner’s investment would be worthless. Your thought of cheating, just a little, quickly flies out of your head, and you go back to being a straight-up miner – and, by the way, watching the other miners closely to make sure none of THEM cheat; if they did it would hurt you. Badly.

    The miners are un-recruited, unmanaged groups who put up their own money and time to make money, and are thoroughly incented to play it straight, without cheating.

    What the miners actually do is solve computationally intensive problems – all using standard software on juiced-up hardware – that does two important things.

    • First, the computing assures that each new transaction that someone tries to put in the ledger follows the rules. Simple rules that are essential to virtual currency working. Things like you can only spend money you have. You can only spend it once. Stuff like that, things you don’t even think about when your money is physical and sits in a wallet — but when it’s digital, has to be enforced.
    • Second, the computing puts a lock on the new transaction, a special fancy lock that links to all the earlier locks on all the prior transactions. For ease of computing, the transactions are grouped into blocks, and it’s actually the blocks that are locked up tight and chained together with cryptology. Thus the name “blockchain.”

    The rules built into the Bitcoin/blockchain software used by all the miners are the key to everything. Since all the miners run the same software, everyone follows the same rules. These rules enforce the fact that, at any given moment, there are a known amount of Bitcoin, with the ledger tracking who owns how much. The number of Bitcoin is fixed – until a miner earns some as a result of the mining work. In that case, brand-new Bitcoin are created – according to an established formula – and deposited in the miner’s own account in the ledger. Once the miner has the earned Bitcoin, he can do anything he likes with it, like any normal owner of Bitcoin.

    Finally, it’s true that the Bitcoin miners see each and every transaction. Each transaction is vetted to assure that the rules are followed. But the owner is identified only by a VERY long string of letters, a key, so no one knows who the owner of Bitcoin is in physical life. This is the capstone of Bitcoin’s solution to the problem of government-issued currency. No snooping!

    Net-net: There is a publicly known amount of Bitcoin in the world, which slowly grows as it is created to pay the miners who earn it by running the system. There are a large number of volunteer miners keeping transactions flowing, safe and secure, without depending on any of them. Bitcoin buying and selling is easy, inexpensive and private. Because of thousands of volunteer miners crunching away. No one’s in charge. Miners want to work and are incented to be honest. No governments, no bureaucracies, no politics, no one snooping on you. Problem solved!

    That’s why Bitcoin/blockchain is new and deserves the attention and credit it’s gotten.

    This post originally appeared on Forbes.

  • Adventures with Health Insurance Software: Customer Feedback

    I got an email from my health insurance company, telling me I had an important message I could read if I clicked and got to their website. Here's what happened. While I was on the site, I discovered they were delivering break-through functionality making it easier to pay those annoying doctor bills that appear in the mail long after the visit. Here's the scoop. This post tells what happened next.

    One of the best things Anthem did to enhance their customer website experience is to be humble. So many stuck-up website creators are sure they’ve done the best job that can be done, and simply put the site out there. Here it is, visitors, we’re sure you’ll agree that it’s a truly excellent website!

    The experienced professionals at Anthem are well past this kind of immature attitude. They worry that the site they’ve build isn’t as good as it could be; how better to find this out than by asking the customers, the actual people who use the site?

    Certain modern website designers get this kind of information in a sneaky, underhanded way. They closely monitor each click and keystroke made by visitors, and track the time between each. This method of surreptitious shadowing enables them to discern exactly when and where visitors get stuck, bogged down, get lost or whatever. That way they can enhance the site and run experiments to make everyone’s experience smoother – without telling anyone what they’re doing!

    It’s amazing the public puts up with this kind of spy-movie tactics! The folks at Anthem aren’t about to be sneaky or underhanded in any way. They’re committed to open, fair and above-board methods. I experienced this myself. When I was in the middle of experiencing their amazing new billing features, I was presented with this screen:

    Pay 2

    It’s an offer to give feedback, via a third-party tool. Excellent! I think I’ll say yes, and give them my feedback.

    I proceeded to experience the fullness of the new, break-through patient billing feature I’ve described here. Then, when I left the site, sure enough, I had my opportunity to provide feedback. I dove in and first saw this screen with a couple questions to which they “require” the answers.

    Pay 8

    What’s that about? This is voluntary, remember? I’m helping you guys. You should be glad to get any feedback I care to give. And I’m not starting out in a great mood because the first couple questions are completely generic.

    So please forgive me, but I zoomed ahead, getting to here

    Pay 9

    Question 23! Sorry, I wasn’t able to get it done. I zoom to what looks like the end:

    Pay a

    Getting personal with the income, are we? After a whole pile of b.s. questions. I’m outa here. But then this appears:

    Pay b

    Yup, 26 questions. ALL OF THEM “REQUIRED.”

    I wonder if anyone tracks the completion rate of these surveys. I suspect not.

    I bet Anthem gets incredibly useful information from these surveys. And increases customer satisfaction along the way. No wonder their site is clearly top-of-the-line.

     

  • Adventures with Health Insurance Software: Provider Billing break-through!

    I personally experienced the roll-out of Anthem BC-BS’s new patient billing initiative. As is well known, and as I’ve discussed in detail, patient billing, both from providers and payers, is a nightmare for everyone involved. Fixing it appears to be tough – it’s worse than being between a rock and a hard place; billing is between a rock, a hard place, the devil and the deep blue sea.

    As I’ve said many times, Anthem is one of the best health insurance companies out there, full of hard-working, well-meaning people who just want to do the right thing. Their many efforts at making things better demonstrate this. But there’s clearly something about being a giant organization with lots of extensive, complex software that seems to make things go wrong. Small, entrepreneurial organizations can sometimes avoid the usual traps and turn out great, high-quality software quickly. But the big, lumbering bureaucracies just can’t seem to follow the clear patterns of success demonstrated by the winning the upstarts. Everything is against winning. They follow the regulations, the best advice of the best experts from industry and academia, and the results are consistent. Consistently bad.

    Getting things badly wrong in software is most often a team effort. When it’s wrong, it’s rarely an ooops, how did that happen? I’ll fix it and then we’ll be OK! It’s more often pervasive, multi-dimensional badness. Anthem’s billing break-through is clearly the typical case.

    In this post, I’ll describe the break-down, the fact that the new billing effort is broken. Again: this is not about Anthem specifically. It’s an example of a pervasive issue.

    What led me to discover the new patient billing feature was an email I got from Anthem. That’s a story in itself, which I tell here.

    While I was on the site, I had occasion to carefully examine the welcome page:

    Pay 05

    I noticed something new since last time I was there – the ability to pay provider bills. Wow! I’d never heard of any insurer offering this capability before. Of course I want to try out this amazing bill-paying break-through.

    I’d better step back for a moment and explain the billing situation in healthcare, because when you just glance at what you’re about to see, you might think it’s no big deal.

    In US healthcare insurance, there’s something called a “co-pay.” This innocent-sounding term is the cheerful face of a nightmare for all involved – patients, providers and insurers. At some point, I have no idea when, someone decided that insured patients should pay a part of their cost of their care, a bit like the well-known general insurance of a deductible, but fancier. The idea is that, for each service a patient gets, insurance would pay part of it, if the service is covered at all. Then, depending on a whole bunch of other things like whether a provider is “in-network,” the patient should pay something to the provider, an amount that the insurance company calculates using arcane formulas that are secret. Here is a detailed example.

    So get this: you have insurance. You go to a covered provider to get a covered service. The insurance company pays some of the provider’s bill. The provider generates a bill for you, sometimes when you check out, but often much later, in the mail. The provider’s bill includes an amount you have to pay directly to the provider. That’s the co-pay.

    This is the context that helps you understand Anthem’s billing break-through: instead of getting random bills in the mail from random providers and having to write checks and mail them various places, Anthem is letting you go to one central place and take care of them. Even electronically! A great convenience.

    Health insurance companies are ideally positioned to provide this service! They already have the complex systems set up to transfer money to providers (doctors and hospitals) electronically, because they’re already paying them! Setting this kind of system up from scratch is hard, and maintaining it with all the changes to bank accounts, etc. takes a lot of work. Leveraging all that infrastructure to enable patients to pay their bills is a great idea.

    Even better, the insurance company knows how much the patient is supposed to pay the provider! Even though the normal procedure is that the providers bills the patient, all the numbers ultimately come from the insurance company. So all the required data and systems are already in place! What a fabulous opportunity!

    Naturally, I dove right in to trying it out. Here’s what I saw right away:

    Pay 3

    Now I’m getting really pumped – it’s exactly what’s needed!

    I ask for the list and see a juicy target to pay:

    Pay 4

    Perfect, a typical co-pay. I click to see the details of the claim. Typical stuff, as expected:

    Pay 5

    Of course, it's a bill that no one but a clueless health insurance company would have the nerve to create. It doesn't tell me who provided the service, when the service was provided, where it was provided or what the service was. Other than that, it's great! Oh and by the way, they don't seem to know whether I actually owe this money or whether I've already paid it. In fact, I happen to know I have already paid it!

    I know, complain, complain. But still, moving ahead…

    I’ll spare you the details of how I had to provide payment information. I did it and authorized payment. Then I got this lovely screen:

    Pay 6

    Yes, that’s the whole screen. The technical term for this kind of screen is “face plant.” A “face slap” is when there’s an error, but the software knows it and can give you a nice error message with something soothing about how things aren’t as bad as they look. When you’re on a site labelled Anthem and then suddenly you’re no longer on their site and some other company’s logo appears, you know that the two bodies of software are in all-out war. You know the war has gone nuclear when the dreaded “500” error appears. That’s not an error message generated by software that is confused and knows it’s in trouble – that’s an internal website server error. This means things have gone so bonkers that the software that’s supposed to handle things has gone AWOL, and all the server can do is say, in technical terms, is OOPS.

    So I re-grouped, went back to the start, picked another bill, put in my credit card information (again!), and authorized payment. Here’s what I got for my trouble:

    Pay 7

    Things are getting better – we’ve advanced from a full-on face plant to a relatively mild face slap error – no one else’s logo is in sight, no servers are complaining (at least visibly). It just plain doesn’t work.

    Anthem presents bills that fail nearly all the criteria required of a reasonable bill. Their bill payment mechanism doesn't work. Even if the final step of paying the bill worked instead of face-planting or face-slapping, it would still be near-worthless! What good is a bill that doesn't actually show what you owe? Doesn't show when, where or by whom the service was provided, or even what the service was?

    Here is the simple conclusion: Anthem claims to have a revolutionary method to enable patients to pay their providers, a great convenience. If it works. Which it doesn’t, to varying levels of embarrassment.

Links

Recent Posts

Categories