Hacker News Reader

Comment by thejohnconway | Hacker News Reader

I use a Dexcom Continuous Blood Glucose Monitor that pairs with this pump (I don't use the pump). And honestly, this is not surprising. The software quality in this space seems really low. I don't understand why some single-developer Mastodon client app can absolutely reliably get notifications to my watch but Dexcom can't. Even on the phone, the app cannot get alerts right at all, sometimes stacking them over an hour or more, but getting the current value for the alert, so you can get like five in a row (ALERT YOUR BLOOD SUGAR IS IN RANGE).

It's kinda terrifying to be honest.

View on HN

I don't understand why some single-developer Mastodon client app can absolutely reliably get notifications to my watch but Dexcom can't.

The same reason why software developed by individuals or small teams can be very high quality, while "enterprise" software is universally horrible; the former work in more self-structured and effective ways, but the latter usually involves tons of bureaucracy. This tends to introduction a selection bias to the types of developers who work in those environments.

Why blame the devs when management is who make the environment?

Or is your point that only lower quality devs have jobs at those places?

smart devs who like to iterate fast and build awesome software will leave rapidly when bogged down with paperwork and compulsory training courses.

And you end up left with only mediocre devs who just want to take the salary and be home by 5pm because they care far more about their family/hobbies/life more than the quality of the app they're building at work.

Yeah imagine those weirdos who care more about their family and lives over the app they build at work.

If your company relies on no-lifers to be successful, you’re running a bad company. This is a management issue.

> And you end up left with only mediocre devs who just want to take the salary and be home by 5pm because they care far more about their family/hobbies/life more than the quality of the app they're building at work.

I think it's amazing that in your mind this is a negative thing.

I think it's the not caring about quality before 5pm that GP was calling out.

Maybe, I'm not sure though. The "because" part is pretty directly saying that caring more about your family/hobbies/life than the app you're building at work is what makes them mediocre developers.

“Because that’s _all_ they care about”

That wasn't the quote. Why did you use quotation marks?

It's of course a very positive thing, but so is creating something great for other people to use.

The economic prosperity that affords us the opportunity to spend leisure time with our loved ones comes exclusively from great creations.

You don’t necessarily have to disregard family/hobbies/life in order to make great creations at work. One can still do great things clocking in at 9AM and clocking out at 5PM. It’s a myth that all great progress comes from Code Ninjas grinding 100 hour weeks, a myth that benefits companies and VC investors only.

Yes I agree - I’m just saying that there’s good things to be done at home and at work and the two must be in balance over the course of a lifetime, or else society decays.

Something about this makes me cringe. Not sure exactly what. I think it's the idea of "iterate fast and build awesome software" as it pertains to high integrity systems.

You don't iterate fast or slow when dealing with this shit. You do it at the exact speed you need to to fully understand the domain, failure modes, validation processes, etc. Similarly, you don't write "awesome software", you write exactly what is needed -- nothing more, nothing less, and what is there needs to go bang every time.

There is no reason to believe an enthusiastic day-tripper who starts getting bored when the grueling FMEA, design validation, etc. starts to kick in is a better choice than the salaryman who's prepared to do what needs to be done for the next 10+ years of the product lifecycle.

I say this as somebody that worked on an unreleased product that was on the cusp of safety critical and am glad that it didn't go to production in hindsight. It desperately needed less "awesome" software and a lot more "paperwork".

I don't think anyone here wants to hear this or understand it, but SWE work needs a hard reality check. I think a lot has been lost in the swirl of easy six figure salaries and recruiters constantly nagging you to jump ship and come work on awesome xyz. A downpour of VC money doing billion dollar shotgun blasts hoping to find just one gem.

Let me put it this way: If you had a team of EE's and ME's who all made between $150k and $250k, you would basically have the cream of the crop. A team that could make mars rovers or infallible pacemakers.

But a team of SWEs making that much? You get buggy weight loss apps and serially broken web access portals.

There are a variety of factors, not all of which may upend things but some probably will at least for certain classes of SWEs. Remote opportunities in lower cost areas, AI, and a glut of people who jumped in because that’s where the dollars were are a few that come to mind.

Doesn’t mean that competent SWEs will be destitute but salaries will probably trend more towards other typical engineering salaries—solid middle class professional salaries.

> smart devs who like to iterate fast and build awesome software will leave rapidly when bogged down with paperwork and compulsory training courses

Sure, when the market was hot this was most likely the case, but not everyone lives in the Bay Area and the choice of jobs that _aren't_ like this is much more slim.

>Why blame the devs when management is who make the environment?

Man, every second thread is something like this; "It's the MBAs! It's the managers!". As if every single employee doesn't affect "the environment".

What do you consider your responsibility, as a developer? Just following orders? Why not have a little accountability?

Devs have little to no control over what work we do when on large enterprise projects.

I’ve known many devs, myself included, who do speak up about user facing issues we’ve been keeping an eye on. We’re routinely ignored, moved to a different team, or, in the worst case, let go.

The best way to affect change is to keep your head down until you’re in a management position.

It’s as they say, “the fish rots from the head”

So you're asking devs to fight a dysfunctional and possibly aggressively punitive organization?

The real-world solution to those situations is the company falters and learns or fails and dies.

Which is why monopolies and TBTF are so toxic to our workplace - bad employers who leverage suppliers/customers in a bad way and institutionalized workers who then move to other organizations and bring their diseased ideology with them make things worse for everyone.

I’ve never met a dev who is pleased to be working on a shitty enterprise app.

In my experience working in enterprise software, we as the devs are far removed from any customer problems.

Those problems, when reported, go through some or all the layers of support engineers, product owners, and engineering managers and eventually get put on some every growing list of stuff to do.

The devs, being so far removed from customers, choose to focus on what they can see, which is usually just whatever feature was prioritized because big customer A was promised it would be ready by some date.

A single dev has no such barriers, as you were saying.

I've occasionally enjoyed working on an enterprise app, but it really depends on the team.

Was it a shitty enterprise app ;)

The two devs I know who worked on enterprise software both ended up getting an MBA on company time to move into management ASAP so they dont have to write code in the awful system and they get paid way more.

They ultimately get incentivized to contribute to the maze of "safe" processes, rule making busywork, and google docs writing for the next layer of management above them.

That’s a route too, sure.

I couldn’t stomach working in management at a big org, personally

I was here to say exactly the same thing but about another insulin pump system.

A few months ago, an update to Roche's DiabetLoop (DBLG1) created a thousand problems with emails recommending temporary tricks, subsequent updates, etc.

It’s unclear how such a serious issue didn’t surface during QA testing for a system that is, ultimately, fully under the control of the manufacturer (hardware/software).

I see a lot of effort to ensure the ecosystem is increasingly closed, touting the need for security of devices that can be fatal, but, in reality, there's little attention given. (And I say this because bugs and issues that everyone reports are always present, they're known, and they’re not being addressed.)

I’d argue that the regulation for ‘alternative control enabled’ (ACE) pumps [1] is too vague. These devices should be ‘designed to reliably and securely communicate with external devices’. These incidents were caused by the app crashing, resulting in the connection re-establishing itself frequently enough to drain the batteries [2]. How reliable should it be? Shouldn’t it include some stability measures?

Manufacturers should have to submit their devices and software for certification of the technology before itself. Bluetooth and coding standards are mature enough at this point, and it’s time customers start demanding this from their products.

[1] https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/cla...

[2] https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res...

Reliability to the degree that medical devices need to be when you're sharecropping on someone else's shifting-sand platform is a game I'm glad I'm not paid to play. It in no way excuses the bad behavior, they chose to go this route and committed to the work it would take, but the results of the such certification would be outdated by the time you finish it.

I think a "sacrificial device" is the right way to make reliable the unreliable parts. Big battery for running the pump, small battery for the smart device connection. If something happens and you drain the auxiliary device it's annoying but not life critical. Your phone and pump can both alert you indicator light/notification that the auxiliary device died.

It's because one app is made by an engineering enthusiast. The other app is made by a company whose primary field isn't software, the executives are most likely wholely inexperienced with software development and/or sometimes nepo hires who then proceed to hire yesman middle managers or even outsource app development.

> The software quality in this space seems really low.

Why is this surprising? No one is willing to spend any money on it.

A developer can make $400K+ at a FAANG and work remotely. Or they can work on-site for a quarter that salary in a medical enterprise company.

FAANGs may suck at hiring good developers, but good developers are excellent at leaving shitty companies.

Want better experiences on this stuff? Start paying embedded developers non-crap amounts of money.

People working in their spare time make better apps than these. I don't think you need great developers, just ones that follow specs and use native development tools would probably do.

In any case, I was responding to the notion that the FDA was quality-controlling these things. They aren't doing a very good job.

> People working in their spare time make better apps than these.

So? If you want better software, pay for it.

This infects all embedded development--not just medical.

Everybody refuses to pay people what they are worth and then wonders why all their software sucks.

> In any case, I was responding to the notion that the FDA was quality-controlling these things. They aren't doing a very good job.

The FDA doesn't exist to ensure something is "good". It exists to ensure that something "does what it says" and "doesn't actively do harm". That's all.

If you want something to be "good", you will somehow have to ensure that there is pressure or money to incentivize such behavior.

What faang allows remote work? What faang has average devs making 400k?

(Also it remains weird to me that Netflix is considered a tech company)

The reality is companies like this often use minimum cost contract companies to develop the software rather than actually employing developers directly. They seeing software engineers (or any non managerial position) as purely an expense not the source of value in their products so you only get penny pinching on development and QA.

I use a Freestyle Libre and think the software is junk too. Lot of proprietary lock-in and trying to push you towards certain vendors in this space.

Should all be about people and not profit. These aren't difficult problems to solve. Nightscout is great, as is xDrip+, but pairing your device with xDrip+ gets you locked out of the vendor app and invalidates your warranty, which is a big deal as sensor quality is hit-and-miss and may come out of your arm before the 15 day window is up, so you won't get a free replacement if that happens.

I would love to figure out DIYing CGMs, but the enzyme-dipped probe is the challenging part.

Also, I don't think smartphones should play an active role in this space. As a means of reading data and perhaps modifying routines on a dedicated device? Maybe. But these things should all function independently of phones.

My phone does an update or runs out of juice? I stop getting CGM data until I unlock with PIN and use the NFC to reconnect. Happened to me last night in my sleep, so missed going hypo in my sleep.

Complete junk in this space, IMO. It's very annoying.

Any device can run out of juice, I'd rather worry about one than two.

My alerts have pretty much always been on time (Dexcom 6 and iPhone 14 Pro Max)

Don't move to the 7. The software has regressed tremendously. It's clearly some sort of cross-platform abomination.

I know that paired pumps have been slow to move to the 7 (only the Tandem has AFAIK; I'm currently on the Omnipod) and I can understand why from what you're describing.

Software aside, how do the accuracy/precision of the readings on the g7 compare to the g6? Not having to replace/order a transmitter every 3 months, and a 30-minute warmup, seem like significant improvements over the g6.

Regarding accuracy, I don't know, because I never compare it to anything. Seems pretty similar based on how I feel vs readings when I'm low.

The hardware experience is indeed better. Bundling the transmitter with the patch and the 30 minute warmup are great, and part of the reason why I haven't got the energy to switch back.

I do a manual test strip test from time to time.

There you go. They optimized developer productivity over everything else.

This is a bit of a wild jump. OP hasn't even explained their grievance with the software.

No, I think that is exactly what happened. They wanted to merge their Android and iOS teams. I described one major bug (the alert stacking).

It seems pretty obviously they are using a cross-platform framework, the buttons and the way alerts are displayed is non-standard. Given that I've never seen a native app struggle so much with it's notifications, I'm going to go out on a limb and say that not dealing with bog-standard native APIs because they are running through a framework might be the problem.

Honestly, I kinda think Apple has some responsibility here too. They should reject these apps, or help the companies figure out what is going wrong.

> They should reject these apps, or help the companies figure out what is going wrong.

This is what the 15/30% Apple tax is supposed to be for. I simply don't understand why they drop the ball so much when they're making a mint from developers (and consumers!).

As a matter of interest, are your issues on iOS or Android? No real reason for asking beyond curiosity...

> Honestly, I kinda think Apple has some responsibility here too. They should reject these apps, or help the companies figure out what is going wrong.

So it's on Apple to basically become a shadow FDA and maintain their own panel of experts to second-guess the whole FDA review process?

If the App Store is meant to have some sort of quality control to justify it’s existence, then yes, they should reject apps this buggy.

They want to have health as a major feature of their platforms. To do that, they have an interest in making sure the most important health apps aren’t garbage.

From the app's perspective, it's working fine, it's just sending commands that crash the device (and even then, the device recovers, but then it gets sent into a boot loop that drains the battery). Does Apple then need to test the app with the actual device, and revalidate it every time the device is updated? Do they need to hire the expertise in medical devices for such review?

I'm fine with more stringent requirements on medical apps, but that should be part of the FDA's review process. Their stamp should actually mean something. If it doesn't, the onus to fix it falls on the FDA (and by extension, the body politic). Apple not so much: their responsibility with health apps has more to do with safeguarding the data's privacy than with the reliability of the device.

Furthermore, if you think Apple is asleep at the switch when it comes to quality control, why would you give them the oversight responsibility for life-and-death-critical software? They should take a package digitally signed by the FDA, do the additional testing that actually is in their wheelhouse (such as data security) then if it passes, publish it as-is. Otherwise, back to the FDA.

oh good grief. There are ways to test the app without being a "shadow FDA".

I admit I was overly dramatic in that phrasing. But there's only so much one can expect the platform vendor to do when it comes to things like medical devices. I'd rather the certification were by an (ostensibly) accountable agency, not the corporation taking a cut of the profit.

I moved to the 7 and have no issues with the (iOS) software whatsoever. What issues are you having? If I had one issue with the 7 it's that it appears much more impacted by bluetooth interference than the 6. I suspect that this is a hardware, not software issue.

For the first few months, the watch would be 20 minutes behind, maybe 60% of the time. About 20% of the time it wouldn't have any readings at all and tell me to check my phone. I almost gave up on the watch (now it pairs directly with the watch it's more reliable).

As I described, I got stacked alerts, sometimes as many as ten arriving in rapid succession with inconsistent readings (Alert: 10.5, Alert: 7.3, Alert: 12.2... etc). Sometimes the reading would actually change while I was looking at the alert. Alerts are particularly unreliable when the phone is in some sort of sleep? I'm not sure, but if the phone is inactive for a while alerts get really flakey.

Dexcom clearly knows about the problems, they continually update the app, and keep say "we're still testing it!"

I've used it on two phones, same problems.

I'm never used an app with such basic problems in its functionality. So the idea that the FDA or Apple are keeping software quality up in this space seems laughable to me.

Reply on news.ycombinator.com