Well, this is a horror story about coding incompetence. There is this nice gadget that can be controlled from your phone to automagically dispense insulin, a real boon to diabetics. You just type how big a dose you need into your phone, and it signals and discreet little device to deliver it. No manual injections!
Except their software drops the initial decimal point. If you type “0.5”, it’s fine, it delivers 0.5 units of insulin. If you type “.5”, it ignores the decimal point, and delivers 5 units. You better not type “.50”, or oh boy, here comes 50 units.
This must have been a fun letter for Omnipod to send out.
Dear Valued Customer,
You are receiving this letter as our records indicate that you are a user of the Omnipod® 5 App from Google Play on your compatible Android smartphone. The app is part of the Omnipod 5 Automated Insulin Delivery System. This notice is a voluntary Medical Device Correction related to an issue with the Omnipod 5 App bolus calculator. Insulet has received 2 reports of adverse events related to this issue.
…
We have received reports from Omnipod 5 smartphone app users where the bolus calculator is not recording the decimal point if it is the first value entered when changing a bolus dose. If the user does not recognize the issue, this may lead to delivery of more insulin than intended, which can lead to severe hypoglycemia.
I’m imagining corporate lawyers having heart attacks when this bug was discovered.
Hey, computer science instructors, this’ll be a good example to use if your students complain about mundane data entry tasks!
Quality-control in software development has been going downhill for a while now. It used to be if you published a bad software product, it was bad forever – like any other product – and potentially killed your company. With the expansion of the internet businesses have discovered that with software if you release bugs you can just release fixes for those bugs next week. Why pay for the extra time to develop and test the product when you can just release it and fix it later? The problem just gets worse over time because if every company is doing it, it’s harder to be the only company that doesn’t. (Full-disclosure: I’m a software developer who specializes in quality and automation.)
I know that people with a condition often become somewhat expert in the language of that condition, but the description in that letter made my head hurt. The press release people need a lesson in clear, understandable, language. I hope the next paragraph spelled out the instructions in clearer language, “do this, not that”. And there better be an app update coming quickly.
I’ve worked in Med device for years (though not software) and I can’t believe this wasn’t picked up in a failure mode analysis. The lengths we go to to understand the implications of any conceivable misuse, mistake, or equipment failure is incredible. This should have been picked up on early.
I don’t understand how you screw this up. Dosing is the most important thing it fucking does- it should be idiot proof. I could certainly see myself not bothering with a leading 0. A friend of mind had to start giving their cat insulin and wasn’t competent enough to read the syringe correctly, so gave her 10x the prescribed dose. After two doses the cat was in great distress in the middle of the night and taken too the animal hospital where they recommended euthanizing her. Yes, it was his fault, but the vet should at least have put tape around the syringe to show the dose or something. Especially with metric, it just confuses a lot of people.
This is not their first problem with entering decimals – from February 2021:
Manufacturer Reason for Recall
Certain foreign user guides include a misprint which could lead to an incorrect bolus delivery and hypoglycemia. Only Outside the US (OUS): Error in the Omnipod DASH User Guide text, page 6 of the User Guide, the text states that the comma (,) is not used for the decimal on the PDM, when in fact it is the period (.) that is not used.If a user were to use the period as a decimal separator when entering a bolus value, this decimal separator would not be recognized by the device and any numbers entered after the period could result in a larger value than intended
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRes/res.cfm?id=185770
Medical device software is notoriously bad, even after the THERAC-25 disaster. Lessons were learned and the industry improved, but medical device companies are not software companies and tend to have blind spots. That’s also why people are wandering around with pacemakers that can receive over the air updates with no authentication- everyone involved just assumed that nobody’d have a radio that could broadcast updates if they weren’t a qualified doctor (when the reality is that it’s incredibly easy to create one).
I’m with andersk3 @2 here: the language of that letter was dangerously vague, and did next to nothing to convey any sense of clear and urgent instruction. It really looks like the person writing that letter either didn’t really understand the problem or the solution, or was more concerned with avoiding corporate liability via vague language and weasel-words (or, you know, both?).
There should have been a sentence like “When entering dosages of less than 1.0, you MUST enter a leading zero (“0″) before the decimal point.” And then maybe follow it with “If you do not enter a leading zero, the system/device will ignore the decimal point…” followed by examples of how badly that can go wrong.
Do I want a spyware platform dispensing my medicine? No.
The proliferation of “apps” requiring network access for doing everything is a plague on society. If dispensing drugs needs to be done electronically, have it be done on purpose-built hardware with its own interface that never connects to the internet. Is that so hard?
It makes it harder to turn a profit selling my private info, so Big Pharma isn’t interested in that approach.
The “move fast and break stuff” is now “move fast and kill folks”.
The one time I had to compose text intended for members of the public I was informed by my organization’s compliance person that I should assume an 8th grade reading level. But it’s not just a matter of vocabulary, it is a matter of clarity.
Though I think in contrast with Raging Bee that the sense of urgency would be clear to any diabetic. I think they learn early on that hypoglycemia is to be avoided at all cost, and severe hypoglycemia even more so.
Also, are there no standard IO libraries? Why are they writing data input code from scratch, and fucking it up?
My coding days are long gone, back in the late 80s and 90s, and even then we’d just import a well-tested, comprehensive library module, and when we wanted a real number from the user, we’d call a function to get a float and it would return a floating point value.
Back in the 70s, maybe, we’d write code to parse a string, but even then you wouldn’t hack it up and forget the decimal point.
If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization
With respect to standard libraries in the Android/IOS area, there are many available, and many of those (especially the “free” ones) are infested with various nasty back doors and trojans.
So you have to do a fair amount of due diligence and be willing to spend some of your budget on proven reliable and safe libraries, be they commercial or open source.
And this is not how things work in many software development shops, speaking from personal experience.
I wonder how they’re reaching out to customers aside from that email. Just thinking about having health complications because some corporation that didn’t understand IT landed an important update in my spam folder makes me twitchy.
anat @ 10
When it comes to anything related to medical equipment and the risk of death, forget writing to an 8th grade reading level. It should be closer to the Dick & Jane reading level. Stories such as this make it clear why I should never be one of the first to sign up for any new product or service. Even when your own inputs are perfect, there is still room for sloppy coding to screw things up.
“have it be done on purpose-built hardware with its own interface that never connects to the internet. Is that so hard?”
“Hard”? Depends on each diabetic’s definition. Nearly everyone already owns a smartphone. A custom interface will be another thing to buy (and when was the last time you heard of a cheap medical device?), it will be another thing to carry, and it will be another thing to recharge or replace batteries on. My guess is that most patients would choose an app over a free-standing piece of hardware.
I always hate when I see the term computer science/scientist since so many in the profession approve(d) of having a dual meaning for the SI kilo prefix, 10^3 and 2^10. That’s pretty darn anti-science in my book, thankfully most are finally coming around to accepting the kibi prefix.
“Chatgpt, code me a user interface for an insulin injector system.”
“Chatgpt, write me an apology letter to our customers who died of siezures. Heartfelt, thoughtful, with no admission of guilt or responsibility.”
PZ@11 Dunno about using existing functions to parse strings to numbers. Of course I normally wouldn’t bother with writing my own parser, but I’ve encountered some cases where standard functions were a bit to lenient with the user’s input and would give me a (completely wrong) value from a screwed up input instead of throwing an error.
Now with the stuff I’m writing these days, the worst that could happen would be someone complaining about an error in their invoice, but if I were to write something serious like that I’d not simply hand over the string to a standard function. Of course I’d put a shitload of error and consistency checks before and after the standard parser, someone else might think writing your own parser would be good idea.
Also wondering where this particular piece of software (or the input library used) was originally written. In Germany for example the .x notation is not used, it’s always 0,x. And yes, the meaning of ‘.’ and ‘,’ are exchanged compared to the US usage when writing numbers. I had fun with that one, I can tell you. And this would also be a potential error I’d think very long about when designing software like that.
Marcus@17: Good point. Even if that wasn’t the cause here, I’m expecting a sentence like that to be the root cause of many future software problems.
The much simpler glucose meter that monitors 24/7 doesn’t always work. And that doesn’t have the potential death side effects of this new tech.
@16 paulhutch
Despite it being a godawful name for a prefix, yes. If I’m forced to make the distinction, I’ll write “Ki” instead of “k”, but damned if I’m not pronouncing it “kilo” in my head.
Initials also matter. What the heck are “UIs?” User interfaces? Unemployment insurance? User instructions? I thought the latter were called “user manuals.”
(Maybe that’s part of the problem here: someone was told to “write the UIs” without knowing what the initials meant…?)
Though I think in contrast with Raging Bee that the sense of urgency would be clear to any diabetic.
The importance of getting the dose right would be clear. That doesn’t mean the importance of following this or that particular instruction in entering the dose would be as clear; especially to someone who might not always be fully alert due to medical condition(s).
My Q is why are we fallible apes are being asked to enter data when there is decades old tech that can do that. Of course the machine needs to ask the humon permission before administering medication.
#19: That’s one of the reasons I used standard libraries: I didn’t have to worry about it. If the user had set up the system to use German conventions, the library would know that and would parse everything appropriately.
Forty-year Registered Nurse here. In defense of the company coding mistake, it is standard medical practice whenever writing a prescription there must be a zero in front of the fractional dose, otherwise it is considered an illegal order. For instance, if a doctor gave a nurse or pharmacist for a prescription for .5mg of (name of medication) they would not accept it and have to contact the doctor for clarification. The order must include a zero in front of the fractional dose, example 0.5 (name of medication). This is done in order to prevent problems exactly like the one mentioned as it is very easy to miss the decimal point if you are busy when dispensing or giving the patient a medication.
With that said, somebody, somewhere during quality control needs to make certain this is not an issue for the patient. Warnings. clarifications and even a return demonstration by the patient should have been in place. A device dispensing a medication where the wrong dose which can easily kill someone should have been tested beyond the normal criteria and make it immune to human stupidity.
PS, there were many changes over my years in nursing as to what abbreviations could be used, sloppy or lazy writing by the doctor and a nurse or pharmacist to lazy or scared to confront the doctor has led to many medical errors which either hurt or kill.
More than 20 years ago, the book “Set Phasers on Stun” adressed this kind of problem in US health care.
The worst example was a machine that if not instructed in the exactly right way delivered two orders more of radiation than intended, thus the book title.
andersk3 @ #2
“Press release people” says marketing to me, and that has potential implications for obfuscation which, based on my experience as a tech writer for software and hardware consumer products, can run counter to “clear, understandable language.”
@1 jsonstache wrote: Why pay for the extra time to develop and test the product when you can just release it and fix it later?
I reply: having ~50yrs experience with computers, I know he is correct. However, for a long time, the greedy corporate world has appended that axiom with: ‘why bother fixing it at all. We’ll release new versions soon.’ BUT, they let that bug remain in the next release and compound it with more new bugs. Too many programmers spoil the broth. WTF
~50 years? I’ve been at it soo long all my hardware is turning to software. And, I keep trying to debug. LOL
It’s not just software. I haven’t seen a company yet that wouldn’t release a product before it was ready. Gotta be first, no matter what!
This bug has been around longer than I can remember. Sounds like they hired some wet-behind-the-ears script-kiddies with zero experience at input validation.
And adding some warning that .5 (or ,5) is going to get you 5 is not acceptable. If the input is invalid, put up a clear error message and do NOTHING. The app should have a standard value, or small range of allowed values, for the specific user. Anything out side that range either gets an error message, or maybe is allowed after multiple confirmations. All of this is obvious (and not exhaustive), and I don’t work on safety critical systems.
@6: Indeed. The Therac fuckup was 35 years ago, and we haven’t learned better yet? As a now-retired programmer, it is depressing to me that the industry seems to have learned nothing since I was a newby making newby mistakes, half a century ago. Failing to notice things like leading decimals points is the sort of thing I was warned about in my first Fortran course in 1976, and would have meant major marks off the assignment. How the fuck are we still shipping safety-critical products with this kind of basic bug you’d expect a high schooler to commit (and learn to avoid!).
@11 (and others): The reason to not just import standard libraries in medical software is that the software has to have a complete “design history”, in the same way that the hardware does. While the impetus behind this is good–we want to 100% know what the software does, is supposed to, and how to trace the implications are if a change is made–it has some counterproductive side effects like the one discussed here.
The FDA (and equivalent agencies around the world), like all government agencies, is somewhat slow moving–but it is moving to catch up. But to give an idea of how far we have to go, it is only recently that OS security updates for medical instruments were exempted from the full test suite required for general software updates, and even that is somewhat scary, given the number of times in my biotech software career that I have seen “minor” OS updates break even well written software.
(My experience is with either software for diagnostic instruments or “software as medical device”, both controlled by the same regulations as devices that directly provide care.)
That’s a good explanation but not really a “defense” since the software could easily have been set up to see no leading zero and simply demand clarification before dispensing.
The concept of having a personal medical device with remote control should be anathema.
Potentially life-critical systems should be protected by strict isolation; local hardware access only, no network access whatsoever.
@#35 –> Totally agree, I was speaking rhetorically to explain the medical part of the equation. There is/are no excuses for medical errors.
@37 Seriously! No exucuses. You obviously don’t work in the field. We are human beings remember.
[OT]
fergl, read both comments by stuffin.
The second is a clarification, to the effect that
“In defense of the company coding mistake”
→
“A likely reason for the company coding mistake”.
Context.
PZ @26 Ironically, the features you rightly point out as a reason to use a library can also be a downside. The more complex the library, the greater the chance there will be some bug lurking. I can’t count the number of times I’ve heard about a widely used library accidentally introducing new security vulnerabilities (AKA bugs) as a side effect of adding a feature.
Were I writing the software to administer a dose based on patient (not even doctor!) text input, I would be terrified of this. If I had to use a library function to parse text into a number, I’d want to evaluate several open source options to find simplest implementation that had the features required for the job, then spend a lot of time carefully auditing it.
THERAC-25 has been brought up already. Everyone who doesn’t know about it should look it up, it was taught in my undergrad computer engineering courses as an object lesson in safety-critical system design. IIRC, the problems which caused injury and death with THERAC-25 were also bad user interface code. Memory is hazy but I recall something about the UI being so slow that expert operators started naturally figuring out ways to race ahead of it, and sometimes this practice led to the operator triggering a bug that caused a radiation overdose.
@jsonstache @1
Yes it started with well testing is a low skill activity that can be outsourced somewhere. Then it continued with the Agile crowds mocked up unit tests are everything , with its added if you have unit tests then you can release quickly! , Then it proceeded to Hey why have QA at all if the devs can write the unit tests with entire QA teams wiped out (I believe Facebook and then aped by other companies with the idea that if a FAANG company does it , it must be copied).
Yep John. Apologies Stuffin.
Having read the email, I can’t help but think the situation being described here is that when attempting to enter a decimal value in the app, the phone’s touchscreen fails to register the decimal point. Then, with the actual amount to be dispensed displayed on the screen, the user proceeds to confirm the incorrect amount twice. The mitigation instructions direct the user to “[d]ouble-check the amount on the Confirm Bolus screen”.
Not good, but hardly the nightmare scenario of incompetent programming and uncaring capitalists presented here. (Note the “URGENT: Medical Device Correction” was issued after 2 reports of adverse effects related to the issue.)
UI’s do matter and on other versions of the software, and apparently future versions of the Android app, the user selects the bolus amount from a drop-down menu of values.
Yikes , I know too many people with diabetes including people I’ve had to call 911 for hypoglycaemia. That’s worse than high blood sugar
@PZ as to whether there is a standard library for handling things like numerical inputs, it is largely language dependent. A lot of times it’s not so much a standard library as it is some random open source library, which can come with a host of issues, some of which mentioned above, some are things like licensing, uncertainty around long term support, etc. Depending on what this app is written in (it is possible that it is written in JavaScript with some kind of iOS and/or Android wrapper to create the illusion of a native app), that language may not have a standard, well tested library to do exactly what the developers needed in a way that they needed, which leads them to writing it themselves (also sometimes the library input components one could pull down have weird design rules and expectations that make them difficult to modify to fit with an overall theme, so many different considerations for app development and design).
That being said, while I see the point of being annoyed by the release and fix bugs later, which is more a result of the speed at which companies seek to get a product to market and less about straight not caring about the quality (though there may be a bit of that as well), one would expect and app that is built for running something medical that can drastically affect someone’s life and well being would have been better QA’d. Hell, most calculator apps accept a .XX for decimals less than 1 and just assume a 0 at the start. While most apps that do this rapid development and deployment tend not to have the whole could affect someone’s wellbeing at the heart of them such that a failure or bug is more just a nuisance than anything, medical apps should probably not skimp on the QA department and be a little more cautious before releasing
@45: ISTM the lack of standard, tested libraries is part of the problem. The way other fields of engineering have achieved reliability is by establishing standard practices — you don’t reinvent the (proverbial or actual) wheel every time you design a new car, or a new bridge. I suggest that standard libraries that have been tested and validated for reliability and security by the best experts in the field, bearing some official stamp of approval, should exist for every major dev environment, and be required for anything deemed critical (medicine, aviation, infrastructure, finance, cybersecurity…..). No one should be writing functions to do basic things like parsing entered text in to floats or whatever, any time after graduation. Or every generation is just going to keep coding up the same bugs.
And I do feel like things have been going downhill. When I was working, we worried about things like race conditions, resource exhaustion, use cases getting left out of some very long list (or the logic that handled all those use cases having grown too complex, and the latest tweak breaking something that previously worked, and really someone should sit down and refactor the whole damn thing). All of which seems like a somewhat higher class of bug than not parsing numbers correctly.
@stevewatson:
Functions to parse numbers are already in tested, standardized libraries. Just about every language has something of the sort built in, often implemented as a passthrough/reuse of code from the very well-established versions in the C Standard Library. (I don’t know offhand how long the “atof” C function has been around, which parses a string and returns a floating-point number, but a quick look on Google confirmed very quickly that it dates back at least as far as the 1989 C standard, and probably goes back further than that.) It’s not a “there are no libraries” problem, it’s a “programmers are not learning the built-in library functions of their languages” problem, and I suspect it has a lot to do with the constant race to jump to whole new languages in the last 20 years or so, rather than to refine existing ones. Why learn the standard library of language X if you’re going to trash all your code and start over with language Y next month, and then do it again next year with language Z?
…then again, even before that tendency became so acute, programmers were notorious for rolling their own date-handling code (and getting it wrong), rather than using built-in library code, so maybe I’m wrong about that one.
Passive voice—the language of our rulers.
“Insulet has received 2 reports of adverse events related to this issue.…If the user does not recognize the issue, this may lead to delivery of more insulin than intended, which can lead to severe hypoglycemia.”
Adverse events. It’s the user’s fault!
reminds me of the saying to error is human the really F.U. you need a computer
@stevewatson: have you worked in software development? Seriously, reinventing the wheel happens all the time and it is for a variety of reasons. The thing is, as an industry, we do try to create standards, and many languages as The Vicar pointed out, have standard functions built in to handle certain common cases (such as number to string and string to number). My only response to that one is we don’t know what language this was written in, and if you’ve ever done string to number conversion in JS, there is thirty ways to do it (possible exaggeration, number is definitely made up :P ), none are standard really, none are consistent. And while there are standards bodies around certain languages, getting new features in, fixes for bugs, etc can take a while.
Open Source largely changed the game when it comes to software development. Getting a product out sooner, despite possible bugs can be both a bad thing and a good thing. A good thing in that the sooner we as developers can get a product into the users’ hands, the sooner we can get feedback on whether the product or new features, etc is good or even usable. Why spend untold person hours perfecting a feature that is going to get discarded because no one finds it useful? But as I stated earlier, sometimes, that level of work is necessary. A good QA tester would have caught the decimal issue sooner. And while we can sit here and say every company should do this, having seen what goes into most startups, that isn’t always a reasonable statement. And unless we are ok with only mega-tech companies owning and building the software we use, it’s just gonna be the nature of things for a while until better automated QA tools come along…
For those mentioning the Therac debacle, that was due to a race condition. This, at first blush would sound like a basic sanity check for dose would be a solution, save that 0.5 units and 50 units aren’t exactly uncommon doses (OK, 50 units is a hefty dose, but I’ve known patients on 20 – 25 unit dose regimens.
As was mentioned by a developer above, it is surprising that a dosing system has such a glaring, potentially lethal error make it out the door – especially, given it took a decade for the artificial pancreas systems to get blessed by the FDA!
This is a software development 101 level fuck up and I’m wondering how that they dug Helen Keller up to evaluate the software.
Because, one cannot count on quite a few patients to know to retain the leading decimal and heaven help granny, who has little Janey to help with the insulin dose!
For any interested in the Therac-25 tragedy, Wikipedia has an excellent article on the subject. Don’t be embarrassed if you get sick after reading about it, I sure did.
20000 – 25000 rads, 1000 rads is frequently lethal.
https://en.wikipedia.org/wiki/Therac-25
I even remember the computer, an old DEC PDP11 series. First computer I ever coded for, got out of school and joined the Army and we used one to program our Pershing missiles guidance systems with one.
As I’ve always said, computers are stupid, they’ll do precisely what you tell them to do, not necessarily what you actually want them to do. So, it’s up to the code jockey to be smarter than the non-sentient device in the room.
Wouldnt it be more accurate to address the letter to, Dear valued hypglycemic customer.
@47, @50: Yes, I’m aware of standard libraries. However, I think others upthread were complaining that some of those had known bugs and security holes. I’m suggesting that, fine: so we create some Certified Bulletproof (to the satisfaction of the most paranoid experts we can find) versions, and mandate that only Certified Bulletproof libraries be permitted in critical applications. Roll-your-own would be just not allowed. Then at least we can create new bugs in the novel, application-specific part of the software, not just repeat mistakes in basic nuts & bolts things we’ve been doing since before most of us here wrote our first “Hello world” program.
@#50, killyosaur:
Ah, but Javascript does have an official, debugged, built-in way to parse strings for floats: Number.parseFloat(). Just because you can coerce strings to numbers via syntactic sugar doesn’t mean Javascript will necessarily do what you think you wanted. You’ve just illustrated my point again: developers don’t bother to learn their languages’ libraries.
(Of course, Javascript — like PHP — is less a “programming language” than a “suppurating pile of bugs which was never intended to be used in any but the absolute most amateur settings”.)
@#53, stevewatson:
How, precisely, do you expect to enforce a ban on roll-your-own code? This is specifically an Android app, where not having a walled garden for apps is seen as a public good, and US government regulation of code quality has a track record of being… less than good, let’s say.
I’m both a software developer and a type 1 diabetic using a pump system, so to nail this from 2 perspectives:
Correct, internationalization (both in values and in dates) comes back to bite us in the ass over and over again. But let’s not focus on this, because even if it was implemented to a tee, numerical input is a big no-no from a usability perspective. People make mistakes, or are generally sloppy at entering data, or have vision impairments, or are (especially in the case of us diabetics) not always 100% clear-thinking when administering doses.
The pumps that us diabetics wear have their own interface to administer doses and the brands that I have seen (Omnipod, Medtronic) do it well. There’s no typed numerical input, there’s just an arrow-up and arrow-down button with which you can change a clearly displayed value, and increments at configurable (but always small) steps. There is always a confirmation step. There are also safeguards against overdosis with (again configurable) limits, and when using glucose monitoring, against taking a dose when glucose levels are already low.
Phones aren’t usually replacing those, because you don’t want to be dependent on a device that can crash, lose power, lost or be otherwise compromised. They’re just a remote control within easier reach. If anything, the apps should mimic the device interface to be clear and unambiguous to the user. Omnipod should know better, but not having seen the app, I would be surprised if there wasn’t a more fool-proof method available to select the dose, and this numerical input is just an advanced option.
I don’t quite think the overdose horror stories are justified. An ongoing bolus (diabetic-speak for an insulin shot) is administered by the pump in tiny, audible steps, and usually and takes minutes to complete. The end of a bolus is signalled with an audible beep. The bolus can always be interrupted if you make a mistake or have second thoughts. And even in the case of an overdose, the effect is far from instantaneous. It takes time for the insuline to sink down to the blood stream, and spread through your system.
… Meaning there is time to take steps and avoid serious hypoglycemia.
@ duckbilled
unfortunately for you and the two (known) cases of direct harm caused by the omnipod, it’s cheaper to make the devices without a built in interface and more profitable to sell you a thing they can declare obsolete in a few years and sell you again when they drop support from the rewrite of the app that will have a new, interesting flaw that will kill somebody.
I’m glad the software I maintain can’t kill anybody through my negligence (as far as I know)
@The Vicar, #47: atof dates to at least 1973, based on its man page entry at https://github.com/dspinellis/unix-history-repo/blob/Research-V3-Snapshot-Development/man/man3/atof.3 . The earliest implementation I found was from 1974 at https://github.com/dspinellis/unix-history-repo/blob/Research-V5-Snapshot-Development/usr/source/s3/atof.s .
Well, tried the Omnipod 5 software, didn’t want to create an account, so bailed on it. Tried their Omnipod 5 simulator, first run it crashed. Second run, it asked for locality information, gave three pages of banner ads and halted.
Not really giving me a warm and fuzzy!
Third run, same three pages of banner ads.
App got mixed reviews though, with about as many 1 star as 5 star reviews. So, I’m guessing it works great if it doesn’t kill you or something.
Not sure if I would have found it; I do test automation, and it would depend on their test rig. However, I DO know several amazing manual testers who would have found it right away. Maybe they need one on staff to double-check everything before it goes out.
Frankly, it looks like a major problem with their entire development process. It’s patently obvious that no attention was given to user centered design. Human factors in general appear to have been ignored as well, as erroneous user input is accepted defectively.
On top of that, production training software is, well, c’est merde. Crashed on first boot, subsequent initiation resulted in precisely zero user interface. Couldn’t check the production software, as I wasn’t about to create an account just to reach a user interface.
I say that the entire development team and their management needs to be launched from a circus cannon. Hopefully, aimed at the local sewage treatment plant. Just so that such leadership can find peerage.
@#58, Andrew Dalke:
Thanks! I knew it was a longstanding POSIX-y C function, but I wasn’t 100% certain that it wasn’t a replacement for something older. (After all, technically atof() is now supposed to be deprecated in favor of strtof()/strtod()/strtold(), and according to the man pages I’ve seen they’re only leaving it in because it would be more of a hassle to update all the existing code that uses it.) If it goes back to 1973 then we can assume it has been in C since the very beginning, because the function was apparently not in B (the language which inspired C) as far as I can tell from the documents available online, and C was literally created in 1972. (I had no idea just how much C added to B before now… B is an incredibly bare-bones language.)
@58,@62:
And if you’re seriously suggesting atof/strtod to handle the OP case, then I believe you haven’t understood the nature of the problem.
Firstly all those style functions have a somewhat complicated set of error cases, which you need to handle as the caller. Point A: And many programmers don’t. Certainly in the OP case I would suggest there is a high likelihood of that. Point B: And my local manpage for all the atoX()-style functions say that each “does not detect errors” only return “the converted value” or(!) “the converted value or 0 on error”. If you think that has simplified your life then you’re in for a world of pain.
Secondly, what they are prepared to handle and what you actually (if you did your requirements analysis correctly!) want to handle are not necessarily the same and the match up isn’t even necessarily knowable. Certainly if a strtoX()-style function indicates some kind of error you can be almost certain that you don’t want to be injecting that. But if it returns success somehow, are you at all sure that you do?
One basic problem here is assuming that because you want to allow fractional amounts to be input, that floating point is an appropriate representation. Actually the amount is quantized, down to tenths of a unit I believe, so in fact a more appropriate representation is fixed-point/decimal. Basically treat all your numbers as pre-multiplied by 10 and only ever do integer maths (if you need to do maths at all) with them. That’s then exact and far more reliable: you can avoid accidentally reading 0.3 as the float 0.2999999999, then using that to program an injection of 0.2 units (which is another class of error you really want to be avoiding here.) Unfortunately standard library support for decimal formats in any given language is usually extremely patchy if it exists at all, so you’re likely going to need to write your own parser for that…
But then we can look one step further and wonder if a text-entry control for a number is an appropriate UI widget for this case at all? The injector pens I’ve seen are basically indexed (clicky) twist to select the dose, then push to inject, so there’s a physical amount of effort required directly proportional to the amount of the dose, and it might actually be a good design idea to preserve an element of that in the app. So, while I usually absolutely hate those spin-the-wheel style number selectors for most purposes, here they 1) tie your actions to a conscious decision to increase/decrease the dose and the size of the action to the extremity of the dose, 2) make clear what inputs are meaningful to the system (they’re the only ones you can choose!), and 3) avoid the need for any kind of parser at all: each selectable option can be directly associated with the internal representation of the value.
@#63, xohjoh2n:
What errors does a parsing function ever need to generate in C? Any memory address is interpretable as the address of a string in C, and it’s the programmer’s job to keep track of which ones are real, so there isn’t even any way for the function to validate that the input “really” is a string. The parsing function finds and parses the first substring which runs (in RE notation) [-?\d*.?\d+], and if there isn’t one, it returns 0 which you are warned it will do in the documentation (and if you want to know whether there are any digits in the string, that’s not the same question and you should be using something else). There’s no memory allocation involved because it returns the value it found as its result. I’m at a loss to even understand what errors you think it should be reporting.
To me, the obvious interface to use — indeed, I had not considered any other option until now — would be a calculator-like set of number buttons, plus a decimal marker and a clear button. Pressing a key other than clear appends that character to the string, which starts as and resets to “0”. Every time a button is pressed, you feed the string through atof() (or some similar) to get a floating point value, then do whatever quantization needs to happen, and then feed the result through whatever formatting system is needed, and print your result on the screen in big clear text so the user knows what the program thinks of their input. (Maybe also put the original string above it in small, faint text, and label both.) We are, after all, talking about an always-positive value whose magnitude is going to be less than 100 and which will already beat manual systems for accuracy if it has one significant decimal place. (Insulin pens only let you choose a whole number of units, and the syringes dispensed for insulin injection, though you can obviously control the amount directly, are never marked with increments of less than 0.1 units at a time (and even that is rare — usually the marked increments are 1 unit).
But you’re right that a text-entry system might not be the best solution — maybe it would be better to present the user with a value in the format XX.X with up and down arrows above each digit so they can adjust them, or something? (Assuming, that is, that the thing really does need to have a greater accuracy than whole units.) And maybe have buttons to immediately set it to the 3 or 4 most recent distinct values to save time if the user commonly alternates between annoying-to-jump-between values like 23 and 18 or something?
(Also: I would kind of hope that whatever the input system is, the program would include some sort of failsafe which, if you requested a dose which was an order of magnitude off from your usual, once there are enough doses to figure out what the usual is, would pop up a confirmation saying something like “At least 90 percent of your most recent doses were from [usual minimum] to [usual maximum] units, but you’ve just requested a dose of [>5 times the usual minimum or <1/5 of the maximum] units. Are you absolutely sure that this value is correct?” I don’t know of any diabetics whose maximum usual dose is more than about 4 times their minimum, so at least alerting the user to a potential order-of-magnitude problem — even if you don’t refuse to do it outright — would seem to be a fairly easy safeguard to build.)
I think Duckbilled Platypus made the most relevant response about UI for medication dosage by patients, @55:
“The pumps that us diabetics wear have their own interface to administer doses and the brands that I have seen (Omnipod, Medtronic) do it well. There’s no typed numerical input, there’s just an arrow-up and arrow-down button with which you can change a clearly displayed value, and increments at configurable (but always small) steps. There is always a confirmation step. There are also safeguards against overdosis with (again configurable) limits, and when using glucose monitoring, against taking a dose when glucose levels are already low.”
Seems much better and much more robust than entering decimal values symbol by symbol.
(Passive safety is the best)
@64:
In your first paragraph you manage to say “number parsing is SOOOOO easy because it has all these complications that spring immediately to my mind…”
Well, firstly, we’re not generally talking about memory safety or anything like that: for a majority of C library functions, that’s on you and the runtime is perfectly happy to let you segfault if you can’t check what you’re feeding it.
No, we’re talking about what happens when you feed inputs that don’t convert cleanly into a number. Either obviously invalid for, or looks superficially ok but doesn’t fit the expected syntax on a technicality, or looks obviously valid but not actually representable in the desired type. And “0 on error” is actually a very real problem in cases where you really do want to distinguish between “user meant 0” and “cat walked on keyboard”. Now you might say that 0 is safe here, but that ain’t necessarily so. Consider:
Should entering “fish” get a dose of 0?
Should entering “five” get a dose of 0?
Should entering “jsadncksjdnc99” get a dose of 0? (Actually above you imply it should give 99…)
Should entering “5-3” get a dose of 5?
Should entering “1e3” get a dose of 1000?
Should entering “1e4000” or “1e-4000” get a dose of 0?
Should entering “0x10” get a dose of 16?
What dose should entering “NaN” or “Inf” get you?
If your reaction to any of those is that they should not be accepted, and the user should be notified that they are not being accepted (which I think, if you’re going to accept numeric entry, is unarguably true), then you should be aware that strtod (and therefore often atof) is likely to accept them and return either a weird number or a zero that can’t be easily justified from the presented input. These are really not good functions to expose directly to a non-expert end user.
As for errors, the most common is signaled by strtod simply by stopping: it tells you where it thinks the end of the number is, if that isn’t the end of the string you gave it and you thought you were feeding it a single number, then clearly there is something unexpected in your input and you should think twice before proceeding. The other case is out-of-range: those “1e4000” and “1e-4000” cases are too big and too small respectively to fit into an ieee double, so you get a specifically signaled range error.
Your calculator keypad idea is actually mostly what you get if you use standard Android UI features and tell it you’re expecting a number. (If you don’t tell it that then you get the standard alphabetic keyboard, which is an instant tell for laziness or inexperience and bugs the hell out of me.) But consider that using the standard toolkit widgets would not have prevented the eventual entering of “.5”, nor prevented subsequently parsing that to 5. Again, if you want to do it right you’re going to have to have some custom domain-specific code here. Which, if you want the round-trip verification display you suggested, you appear to be onboard with because you ain’t gonna get that in any “standard” function or UI widget.The problem is not “didn’t use standard library features” but “didn’t understand what they were really doing whichever way they chose to do it”. I wonder if the ultimate problem is “not considering the app to be part of the device” and therefore not subject to the same safety regime as the pump, and therefore attractively cheaper to produce. I then wonder if the FDA are on board with that way of thinking, or whether they even noticed it…
xohjoh2n, what is sanity checking and bounds checking again?
Proper input processing would simply reject erroneous information, discounting the entire entry, so that it could be re-input correctly.
After all, most would consider it undesirable to hit a bump in the road while entering a dose of 0.5 and instead getting 5E3 units. For, that forks the road onto the road of wrecked weekend plans.
@67:
Something that the C standard library firmly believes is “your problem”. So if you believe that using a C standard library function, or anything built lightly on top of it, resolves your data validation problems, you’re in for a bad time.
(Different standard libraries have wildly different approaches, but quite a few are in fact built on top of the C standard library.)