someone tell me : has garmin always been this "bad" or is something going on recently?

2529455 said:

Have you worked there? How would you even know?

I read employee reviews on Glassdoor and other similar sites. I was curious at one point and even entertained an idea of working for Garmin. But their engineering salaries are below industry average and also they require relocation to Kansas, so I quickly dismissed the idea.

Suunto has a renewed focus on trail and ultra niche where they excelled in the past. I look at their latest watches - Vertical and Race - with a lot of interest. I used Suunto watches in the past and they always were rock solid, although a bit simplistic. Coros is also doing everything right. They have a focus on simplicity and usability. I know a lot of former Garmin owners who switched to Coros. Also Coros does a great job at sponsoring some major trail ultrarunning athletes, including Killian Jornet.

In contrast, Garmin doesn't really understand trail running based on my experience. Their watches are primarily targeting either road runners or hikers, with trail running being an afterthought. They don't even seem to have any major sponsored trail ultrarunning athletes, at least none that I could find any information about. Unlike road running or hiking, trail running has several unique aspects, like the pace that varies in a great range. It covers a broad spectrum of activities from running on flat and non-technical terrain and all the way to mountaineering. I can also tell that map and navigation UX isn't optimized for quickly glancing at the display while moving fast.

FlowState said:

I could also point to a podcast about Garmin device internals which explains that Garmins don't have a proper OS (e.g. no processes or memory protection)

Perhaps Garmin have attempted to run a kernel with user/kernel modes plus process isolation and ended up realising that they'd have to use 512Mb RAM rather than 5MB along with a processor running at 4x the clock rate. Perhaps that ended up bringing the battery life back from 30 days to 5. Perhaps that would then have customers thinking "well that ain't much better than a Apple Watch Ultra which has 10x more functionality. I'll just buy that given that I'm pretty much charging them both multiple times a week".

Every design choice is a compromise. I doubt they've opted not to implement these features due to lack of competence (as you say it, "old-school") within the engineering teams, particularly when you're able to buy an RTOS or even cut Linux down to fit a wearable spec. There's a reason for it why GarminOS is so pared back and it most likely comes down to battery life (keeping RAM and clock to a minimum) along with deciding that the ConnectIQ VM can do a "good enough" job of protecting 3rd party code from the OS.

There probably will come a time when Garmin opt for a richer OS when the hardware and battery specs are ready for it, but it currently does a pretty good job of hiding it's limitations when you consider the actual functionality you're getting from a UX perspective with current models.

So before shooting off with really strong opinions labelling a company as old-school or having a poor engineering culture, just first stop and think why is the way it is? If we all attempted strong-man the others position, we might just land a little closer to the truth. This is what I mean by critical thought.

I'm not a "fanboy". I don't even defend companies unless I know something completely untruthful has been said. What I do attempt to do is cut through the emotion, the dogma and gross generalisations people tend make when they're upset about something in the hope of getting closer to the truth about an issue.

All of that said, I'd be very keen to be a fly on the wall in a Garmin engineering team to see if the recent-ish decision to push feature updates every quarter is rushing teams to the point where they're making more mistakes or whether the beta test program is exposing pre-prod bugs to people who feel that the the software should be more stable than it is - hence causing some customer agitation.

The last time I dug into this, the lack of "proper OS" etc. in Garmin watches wasn't a software engineering choice. It's simply because the hardware inside the watches doesn't have a memory management unit etc. needed for memory protection and other "modern" OS features. And that is because the processor they use have intentionally been stripped down to cut power consumption and maximise battery life.

So yes, it's a hardware compromise (or rather different prioritization) that limits what can be done in software.

Similarly, the watch has less RAM memory compared to beefier smartwatches, and even that is partitioned so that the CPU can shut down unused parts of the RAM (and powering it up requires a couple of milliseconds, probably).  So writing software in such an environment is unavoidably more challenging than what most software engineers are used to nowadays.

It is getting worse. There are to many new bugs introduced in last 2 years, and Garmin was (and still is) extemely slow to react and recognize the problems (even when users report them), let alone to fix them. All of that cannot be coincidence.

As a buyer of expensive device, I do not care how easy or difficult it is for engineers to do their job, I am interested in how well they do it. Currently, significant improvement is needed.

Interesting and related discussion few months ago: https://forums.garmin.com/outdoor-recreation/outdoor-recreation/f/fenix-7-series/365838/devs-at-garmin-do-you-test-software-before-releasing-it?pifragment-1292=1#1771686

Bitti said:

The last time I dug into this, the lack of "proper OS" etc. in Garmin watches wasn't a software engineering choice. It's simply because the hardware inside the watches doesn't have a memory management unit etc

Garmin use the NXP i.MX RT500 with the Fenix 7 series (and probably most other watches)

https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt500-crossover-mcu-with-arm-cortex-m33-dsp-and-gpu-cores:i.MX-RT500

Its capable of running Zephyr RTOS which offers user/kernel modes with memory protection, though I don't know if the RT500 offers the requisite memory protection unit to run this.

https://docs.zephyrproject.org/latest/kernel/usermode/memory_domain.html

Other NXP and Qualcomm processors do obviously, so again it probably comes down to a compromise on power use, cost and functionality they want to offer.

Update: The block diagram indicates that the RT500 does have an MPU. The decision of running a single task at a time (I'm guessing in an RTOS fashion to guarantee a certain response time) is likely down to the RT500 having 5MB of onboard memory and not having the need to run background processes (apps).

This requirement might change in the future when we potentially have multiple background process (think chat apps) listening over LTE, but you could still potentially serialize these apps out of memory, loading them back in once every few seconds and handing the TCP connection back to them.

Interesting to see what designs choices get made. Heck, they might even opt to run a cut down version of WearOS in future.

Vizi said:

As a buyer of expensive device, I do not care how easy or difficult it is for engineers to do their job, I am interested in how well they do it.

Exactly. The implementation isn't as important as the user experience.

2529455 said:

So before shooting off with really strong opinions labelling a company as old-school or having a poor engineering culture, just first stop and think why is the way it is? If we all attempted strong-man the others position, we might just land a little closer to the truth. This is what I mean by critical thought.

I didn't say there aren't good reasons for Garmin devices (and Garmin) to be the way they are. I understand the battery life argument very well.

I'm just saying that it's not surprising to see the type of bugs (and UX/design issues) that recur.

You don't think Garmin is old school? It comes through in a lot of ways, including the design and functionality of their products, and their oft-criticized market segmentation strategy. Not all of that is necessarily bad. I love the way Garmin devices can (theoretically) be used without ever connecting to a phone, which is more than you can say for Apple Watch. AW doesn't even let you look at your workout history on the watch.

As far as poor engineering culture goes, I admit it's pure speculation. I just see the same bugs come and go over and over again through the years (search "connect iq half cadence bug"), as well as certain very frustrating design and implementation issues with Connect IQ. I've seen a lot of new CIQ devs (both hobbyist and pro) jump into development with wide-eyed enthusiasm, only to have their souls almost instantly crushed by various issues in the ecosystem.

Yeah, I know the CIQ team is very small and I'm sure everyone is very passionate, but at least as far as CIQ goes, some of the problems seemingly speak to the company leadership's lack of care towards CIQ. And I feel the same way about certain glaring device bugs (especially at release.)

I've also seen a lot of very annoying UX issues in things like the Connect app (e.g. selecting a different pair of shoes in Gear doesn't deselect the currently selected pair; you can't add or remove shoes from the Gear tab if shoes are already selected, you have to go somewhere else) as well as the Spotify app. I could write endless paragraphs about this stuff, but I won't. For whatever reason, Garmin isn't good at UX from my POV. Maybe they have a great engineering culture, but that doesn't help when the outcome regarding bugs and UX is still subpar.

Again, I will say that Garmin's UX has improved a lot over the years.

2529455 said:

Every design choice is a compromise. I doubt they've opted not to implement these features due to lack of competence (as you say it, "old-school") within the engineering teams

I don't claim that old-school = "lack of competence". I also don't claim that Garmin device architecture is a bad design. I agree that it's clearly the result of a focus on battery life. I have seen bad design decisions in CIQ, for whatever it's worth.

I do claim that an old-school engineering mindset does lead to certain kinds of problems. I worked at an old-school hardware company for years, and I recently worked at a startup, so I can see the pros and cons of both models.

The engineers at the old school company were very competent in many ways, especially when it came to hardware / device driver expertise. But they had blind spots when it came to certain modern software development practices.

At the old-school company, there was no code review (ppl just pushed whatever commits they wanted, with no automated testing), and some of the engineers would get annoyed if you proactively found bugs in their code. We also had entirely predictable (yet rare) cases where one engineer would wipe out another engineer’s changes when resolving merge conflicts manually, bc everyone used 2-way compare instead of 3-way compare.

At some point the old school company jumped on the agile train (while remaining old school in many other ways), which basically amounted to taking the worst of both worlds. At that company, I just spent years and years tilting at windmills, trying to improve stuff and being ignored by management. It got to the point where I could predict issues years in advance, based on certain design decisions. So maybe I'm a little biased. 

I don't claim Garmin is like that (I sure hope they aren't), but there's def hints of an old school culture when I look certain design / implementation issues in CIQ, and the way certain device bugs recur (seems to indicate a lack of automated regression tests).

2529455 said:

All of that said, I'd be very keen to be a fly on the wall in a Garmin engineering team to see if the recent-ish decision to push feature updates every quarter is rushing teams to the point where they're making more mistakes or whether the beta test program is exposing pre-prod bugs to people who feel that the the software should be more stable than it is - hence causing some customer agitation.

Thank you for at least allowing for the possibility that Garmins may have stability issues (real or perceived).

It's interesting, bc this recent decision that you mentioned has been cited by DCR as a step in the right direction for Garmin software stability, which is kind of ironic.

What i have an issue is with some ppl (not you) claiming that Garmin has no problems (or no more problems than should be reasonably expected), and claiming that ppl who say otherwise are just complainers.

Bitti said:

The last time I dug into this, the lack of "proper OS" etc. in Garmin watches wasn't a software engineering choice. It's simply because the hardware inside the watches doesn't have a memory management unit etc. needed for memory protection and other "modern" OS features. And that is because the processor they use have intentionally been stripped down to cut power consumption and maximise battery life.

So yes, it's a hardware compromise (or rather different prioritization) that limits what can be done in software.

I agree with this and I never meant to suggest otherwise.

The point is that regardless of the underlying reasons, Garmin's device architecture seems to make it harder to write code that doesn't crash. I gave the example of how there used to be a bug in the CIQ framework where an app could bring the whole system down. If you're curious, a simple out of bounds array access would cause the device to reboot. If you put this code in a CIQ data field, then it would be possible for the device to enter an endless reboot loop that could only be interrupted by pressing a certain sequence of buttons at the right time. This is bc the device would reboot and automatically reopen the activity that had caused the crash in the first place, without removing the offending CIQ app. To Garmin's credit, they fixed this bug and they also added logic to automatically remove a CIQ data field from an activity if it crashes at a certain point.

As an imperfect analogy, at my old school company we worked on embedded devices where the primary language was C. Many engineers had a habit of using strcpy, which is known to be unsafe. I tried to speak out against this practice, and I went as far as to implement a simple safe strcpy wrapper. Everyone else ignored the presence of this wrapper and continued to use strcpy, which is fine (i wasn't the boss of them.) I'll let you guess whether we ended up having software that crashed due to the unchecked usage of strcpy().

In this case, the use of C (along with the lack of a management-level policy against using directly unsafe functions) contributed to an environment where certain types of bugs were likely. This is not to say that it's wrong to use C (although some might go that far), but just that the easily predictable outcome was that our devices had preventable crashes due to use of strcpy().

When i brought up stuff like this to management, their response would always be "there will always be bugs". Ofc it's easier to react to problems (when the user notices) as opposed to being proactive, even when you have employees who go out of their way to swim against the current.

Bitti said:

So writing software in such an environment is unavoidably more challenging than what most software engineers are used to nowadays.

Yeah so this goes back to my point. It's not about pointing fingers, it's about being realistic. As the comment I quoted said, it's a "punishing environment" where it seems that we should expect certain types of bugs.

2529455 said:

Vizi said:

As a buyer of expensive device, I do not care how easy or difficult it is for engineers to do their job, I am interested in how well they do it.

Exactly. The implementation isn't as important as the user experience.

And from my pov (I can't speak for anyone else), the user experience could be improved. UX is more than just battery life and a form factor that some users want (although both of those things are where Garmin differentiates itself from Apple Watch and Android.)

2529455 said:

FlowState said:

Why not? Personally I don’t blame any issues on any individual engineers at Garmin, I think it’s clearly a company culture issue. (Garmin obviously has a very old school culture — I don’t work there but it’s obvious when I look at stuff like Connect IQ, which I’ve worked with extensively. Clearly they are trying to change some of that.)

I've been in a dev role for years (now a senior at a large tech company). I certainly don't have the confidence to make blanket statements like you have, besides that maybe the integration testing is lacking if regression issues keep popping up which they do from time to time. I know nothing about the how the teams run. I don't know work there, nor do I know anyone within the company and you don't either. I'm certainly not cocky enough to make statements about quality or engineering practice based upon their ConnectIQ API.

You're right. I don't know anything about Garmin's culture or engineering practices.

I just know what I see as a user, and it's disappointing at times. I see bugs that have persisted for years and it's frustrating. I once reported a bug in CIQ (a config problem with a simple fix) that was acknowledged almost immediately, which was great. Years passed and it wasn't fixed. I posted another message in the same thread, got some pushback from a forum regular who downplayed the bug (just as they did initially), but the CIQ team responded again and fixed the problem. So it looks like they just forgot to fix it originally? That's fine, these things happen, but it's frustrating to me.

You may think I'm overly critical or cocky, but the only reason I criticize Garmin is because I obviously like their products and I want them to be better. Yeah, I realize that complaining on a forum won't change anything.

I have reported several device bugs to product support (again, taking the time to test and re-test, so I could provide useful reproduction procedures), which were eventually fixed. I've also investigated and reported CIQ bugs, which were also fixed. Yeah, all of that is a drop in the ocean and nobody forced me to do anything. My point is I've done more than complain.

I'll say something positive to balance out everything else: Garmin is really great at replacing dead/broken accessories like HR straps, free of charge.

I'll also clarify that I don't think I have all the answers (or any answers), or that I could do things better. I do wish Garmin could do better, that's all.

Garmin seems to be increasingly driven by the finance team rather than the needs of the customer or the athletes there in.  

They bought Navionics and killed it by quadrupling the price and restricting the devices.

They won't open up their eco system to allow all but very few partners to write sync to their databases (even Fitbit is two way).  The only way to get weight into garmin it to buy their WAY overpriced scale (4x reasonable competitive prices) or enter it manually.

I have been with Garmin as a customer for over a decade, and its sad that they have seemed to have lost their way.