Where are you, ladies and gentlemen developers?

Same was when Fenix 6 was released, same when Fenix 7. Nothing new uder the sun - that;s normal Garmin practice, releasing beta software with new product release. Same was, as I remember, with other equipment, like Montana 70 or GPSMap 66. One - three months and all serious bugs will be repaired (in case of handhelds more). Unless you're like Apple, which releases beta versions of next gen software to the public (but then all new features are known), this is quite "normal", as there's no possibility to have such extensive group of beta testers. Wha amuses me, is that anybody still is surprised by this fact. Same will happen with Fenix 9, 10 or any other new product. That's also the reason, why any watches  with real pro features, like avation features and dive features (Marq Aviator, Descent, Tactix) are released few months later - when major bugs are repaired. This is how things are going in life, my friend, not a shame, just life. 

Furthermore it was most likely not the software development teams decision to pin the release to UTMB24 ;)

But yeah, what amuses me even more is the bunch of first buyers, early adopters, that pay the horrendous price and expect to be treated as premium customers, whose concerns and reports should be handled in the blink of an eye. Just because they paid for a product.

Don't get me wrong, I really can't understand what drives Garmin to do so and wish they would get a grip on their profession.

I bet most Garmin developers never run their code on a real watch hardware. They all sit in front of displays of their workstations or laptops, and the code runs in simulators. That's why it often behaves subtly differently than in real life. That's where all these weird crashes come from.

Furthermore, what often happens is that one developer works on feature A, another developer works on feature B, and both of these features are implemented in isolation from each other. But then it turns out these features don't work together. For example a lot of Fenix 8 bugs seem to be caused by changes in their UI and settings, and some settings being being lost in translation or moved to another place. Suddenly a whole feature ends up being disabled with no setting to turn it on, like turn notifications in Fenix 8. At the same time, a new feature like voice announcements for turn notifications ends up being turned on by default on Fenix 7 with no way to turn it off. This points to some high level changes in the organization of the watch settings.

What is more surprising is the lack of field testing before they release it to the public. 

I don;t think so. This is not decision of software development team to release product / software or to allocate adequate resources for testing. Testing is done now - first buyers are making it. That's normal Garmin's (and not only) commercial practice. Thats life, in a moth-three, nobody will remember this mess and everybody will be happy with their watch (after beta testing in real life) Rgds

The problem with this approach is that 90% of users use 10% of features. So then many less frequently used features end up being broken or half baked for a long time, and sometimes are never fixed because Garmin thinks that not many enough people complain about them. 

So now when you think you can rely on your watch in an ultramarathon, and course points don't show on the Up Ahead ahead, do you seriously think that would be fixed one month later? We'd be very lucky if that get fixed one year later. 

Vol22 said:

there's no possibility to have such extensive group of beta testers.

software development manager here - let me refine that a little bit: any software can be tested to that extent that critical bugs do not exist (think about mission critical software)

it is always a management decision to set the targets of the QA.

the problem here is that we cannot experience any level of management regarding QA - garmin's software are so full of critical bugs that even a very basic manual testing (=costs basically nothing) should find those easily

at this point we can presume safely that there is no QA at garmin (at least in the consumer dep) at all.

zero. none. nothing.

so yes, consumer products should not arrive in this state to the market - regardless of having a public beta release, or not.

silentvoyager said:

90% of users use 10% of features

everyone uses the WHR and there are zillion threads about how broken they are for years now.

still no fix, no nothing

garmin does not care whether it is a used feature or not.

or, just the opposite, you can safely count on that we will have a new dog walking activity soon, or oat tipping activity for that matter, yay!

Vol22 said:

everybody will be happy with their watch (after beta testing in real life)

well, not really

please open any forums of old products. the reality is that even functions that worked before, will be broken soon with new updates

we just get used to, and living with workarounds, that's all

I have to fully agree with this. I am also involved in professional software development, and the symptoms seen on Garmin consumer devices - specifically in the Sports and Fitness department - clearly indicate a lack of a proper QA concept.

Now, putting strategies, goals, and implementations aside: it should be a matter of course for any professional software developer's integrity to ensure at least basic functionality through automated testing. This standard should be upheld across all organizational units as well! Yes, this increases development effort, but it prevents embarrassing releases, outages, and regression errors as seen here.

What I have seen in terms of regression errors across the releases on Fenix watches is truly concerning.