April 20, 2004

Digital X-rays, easy; patient's name, unfixable

A full-scale root canal operation on a painful back molar this morning. In the chair by 7 a.m., injections, drilling, tunneling, filing, scouring, filling, bonding, the entire nerve canal system packed with high-strength cementing material by about 8:30, no more pain. The technology is fantastic: a digital X-ray system hooked to a computer with double flat-panel color monitor displays. Using only 10% of what used to be a low X-ray dose, the endodontist can get a large zoomable X-ray image of how it's going, any time he needs it. I could view the progress on the tooth about eight times during the operation. Space-age stuff. And yet there was a glitch. A linguistic problem.

The file for me as a patient of the endodontist 's practice said "Geoffrey Pullum", as it should. But the file set up for my X-ray pictures said "Geoffrey Pullom". The system should have been set up to read my name from the patient database, of course: there should be just one place where "Pullum" is stored, and all files set up in connection with me should link to that. But the systems were not linkable, and someone had to type in my name again, somewhere else, this time wrongly spelled. The incorrect spelling showed in the header bar of the window and the task bar button at the bottom.

Now, of course, this is a serious business: right now, a search of their records is going to find a patient called Pullum who had an operation but without X-rays, and a patient called Pullom who'd been X-rayed eight times for nothing but had received no treatment. Malpractice suits have arisen out of far less. They've got to get their records straight if my X-rays are going to be findable at the next appointment.

I watched for quite a while as the assistant struggled to find out where that spurious name was recorded, and she just couldn't. I knew the pain she was in: from where I lay in the patient's chair, I could see it was Microsoft Windows. I've downloaded things and been totally unable to find them; tried to trace links and found that filenames didn't match them; hunted for folders mysteriously hidden tried to block pop-ups and other behaviors with no success; struggled to customize things and failed. The MS Windows interface is a gimmick-bedecked ill-designed nightmare for an intelligent person, with designed-in blocks to investigation (hidden files, unremovable program components, secret stuff stashed away). Every sensible effort the assistant made, (closing files, reopening them, looking in pull-down menus, checking other screens of information, hunting for anywhere "Pullom" might be located) was a failure. The system, designed for what was supposed to be ease of use, was intractably unusable once something had to be altered. The designers had perhaps imagined their way through a perfect, error-free session, but had not thought about what an error might lead to, or about how trouble-shooting and recovery from error might be perspicuously done. The screen was complex and pretty and littered with brightly-colored gadgets and boxes and features, but it gave no clue as to where that name in the header bar might come from or where one might look for a way to edit it.

In other words, as usual, the hardware guys had done a wonderful job, and the graphics guys who wrote the digital X-ray viewing algorithms had done theirs too, but the interface programmers had let the side down. It is the usual familiar story of modern computing: hardware developments of breathtaking, intergalactic wonderfulness ruined by the low quality of the software that is supposed to let human beings converse and interact with it. What's involved in programming front ends is straightforward: crystal-clear thinking about the structure of systems (computer and human) of extraordinary complexity. It's rather like linguistics (and let me hasten to add, we humans are not exactly great at that either). And it turns out to be much harder than designing and building complex machinery. Either that or software developers just aren't trying hard enough. As I watch software firms upgrading programs to new versions that are more complex, slower, and often objectively worse than the old ones, I often wonder whether the latter isn't the problem.

Posted by Geoffrey K. Pullum at April 20, 2004 02:20 PM